Re: [Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

The problem in TeX Live has just been fixed. Now it will expand short
names: https://tug.org/pipermail/tex-live/2023-November/049706.html
Therefore please feel free to ignore my original request. Thank you!

Regards,
Yihui
--
https://yihui.org


On Thu, Nov 16, 2023 at 8:28 AM Tomas Kalibera  wrote:
>
>
> On 10/31/23 10:05, Duncan Murdoch wrote:
> > On 31/10/2023 4:32 a.m., Tomas Kalibera wrote:
> >>
> >> On 10/30/23 19:07, Yihui Xie wrote:
> >>> Sure. I'm not sure if it's possible to make it easier to reproduce,
> >>> but for now the example would require installing TinyTeX (via
> >>> tinytex::install_tinytex(), which can be later uninstalled cleanly via
> >>> tinytex::uninstall_tinytex() after you finish the investigation). Then
> >>> run:
> >>>
> >>>system2('fmtutil-sys', '--all')
> >>># or tinytex:::fmtutil() if fmtutil-sys.exe is not on PATH
> >>>
> >>> and TeX Live would throw an error like this:
> >>>
> >>> ...\username\AppData\Roaming\TinyTeX\bin\windows\runscript.tlu:864: no
> >>> appropriate script or program found: fmtuti~1
> >>>
> >>> The command "fmtutil-sys" is longer than 8 characters and hence
> >>> shortened to "fmtutil~1". Yes, in principle, TeX Live should work with
> >>> short path names, but it doesn't at the moment. I haven't figured out
> >>> if it was a recent breakage in TeX Live or not (I've tried to contact
> >>> TeX Live developers).
> >>>
> >>> BTW, shell('fmtutil-sys --all') works fine.
> >>
> >> I can reproduce the problem, also separately from R. It is not an R
> >> problem
> >>
> >> ./fmtutil-sys.exe --version
> >> works
> >>
> >> ./fmtuti~1 --version
> >> doesn't work
> >>
> >> The problem is in runscript.tlu, when it looks at "progname", it parses
> >> it assuming it is the full name, looking for "-sys" suffix, which won't
> >> be in the short name:
> >>
> >> progname, substcount = string.gsub(progname, '%-sys$', '')
> >> local sysprog = (substcount > 0) -- true if there was a -sys suffix
> >> removed
> >>
> >> and it does further processing using the program name.
> >>
> >> This has to be fixed on the luatex end, it must be able to work with
> >> short paths (e.g. expand it appropriately). You could probably work
> >> around the installation before it gets fixed, e.g. by creating another
> >> wrapper which would expand to long names, delete the short name, patch
> >> the script, etc. After all, if it works via a shell, then probably the
> >> shell is expanding to the long names and you have a work-around (I don't
> >> know how reliable).
> >>
> >> Adding an option to R's system*() functions to use only long names
> >> doesn't make sense.
> >
> > On the other hand, not modifying the executable name would make a lot
> > of sense, wouldn't it?  I'm pretty sure all supported versions of
> > Windows can handle long filenames.
>
> There could be an option to pass the "module" name directly, which would
> end up as the first argument of CreateProcess, so avoid the search-path
> lookup and the complete path expansion. That would make sense, but I am
> not persuaded it is needed. I don't think the luatex wrapper bug is a
> strong enough case to complicate the code and API (which is already
> rather complicated) any further. It would not be "just" a new option,
> but also dissecting the module name from the command (when not using a
> shell).
>
> While thinking about this and reading the related code I found a bug in
> handling paths with spaces when short paths are not available, fixed now.
>
> Tomas
>
> >
> > Duncan Murdoch
> >

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

Re: [Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

Okay, thanks everyone for the clear explanations! Now I understand it
much better.

Before I wrote to r-devel, I guessed it was probably a problem on TeX
Live's side rather than R, therefore I also reported it to them and
I'm still waiting for a response. If they cannot fix it, and R's
system() has to use short paths, I will resort to workarounds. Many
thanks again!

Regards,
Yihui



On Tue, Oct 31, 2023 at 4:22 AM Tomas Kalibera  wrote:
>
> On 10/30/23 21:36, Yihui Xie wrote:
>
> I have read about "system() not using a shell on Windows" on the help
> page many times before but never understood what it means technically.
> Please forgive my ignorance. I still do not understand it, but thanks
> a lot for the explanation anyway!
>
> As the documentation says, system() on Windows runs the command directly, 
> without a shell (without cmd.exe). As it says,
>
> 'command must be an executable (extensions ‘.exe’, ‘.com’) or a batch file 
> (extensions ‘.cmd’ and ‘.bat’): these extensions are tried in turn if none is 
> supplied. This means that redirection, pipes, DOS internal commands, ... 
> cannot be used: see shell if you want to pass a shell command-line. '
>
> Things like redirection, pipes, etc are implemented by a shell, you can use 
> shell() to run a command via "cmd.exe /c ...", so these would work.
>
> I'm just curious if the full path
> would work in system() today. If it still would not work because
> today's Windows is still like Windows 95 in this aspect, please ignore
> my question and I will ask Microsoft for a refund.
>
> I am not sure if you are asking a general question or specifically still for 
> this use. In principle, short names are still useful to get rid of spaces 
> (sometimes they are not quoted correctly, sometimes they cannot be quoted 
> correctly such as in make). Also short names reduce the risk of running over 
> the path-length limits. So R uses short names when they are available, but 
> supports also long names and tries itself to quote properly.
>
> You have run into a case when an external wrapper has a bug and isn't able to 
> deal with short names. There could easily be other wrappers around, which 
> have a different bug and cannot deal with long names, e.g. because of spaces, 
> when passing them to other programs. Very much like in luatex. And they may 
> have been written in times when they actually were correct.
>
> Best Tomas
>
> Regards,
> Yihui
>
>
>
> On Mon, Oct 30, 2023 at 3:03 PM Prof Brian Ripley  
> wrote:
>
> On 30/10/2023 16:18, Yihui Xie wrote:
>
> Hi,
>
> It may have been so for 20+ years but I just discovered today that system()
> would always try to use the short path of a command on Windows:
> https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
> that's true, I wonder if it could provide an option to disable this
> behavior, because we recently ran into a case in which short paths wouldn't
> work. I wonder what the original motivation of using short paths was. If it
> was to avoid spaces in paths, wouldn't shQuote() work? Thanks!
>
> No: system on Windows does not use a shell.
>
> The 'original motivation' was to work reliably!  Back in the days of
> Windows 95 when many parts of Windows only supported 8+3 names.
>
> Regards,
> Yihui
>
>   [[alternative HTML version deleted]]
>
> Please do re-read the posting guide.  It has ' been so for 20+ years '.
>
> My apologies! Sometimes I forget to switch to the plain-text mode when
> writing to R mailing lists.
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> __
> 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] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

I have read about "system() not using a shell on Windows" on the help
page many times before but never understood what it means technically.
Please forgive my ignorance. I still do not understand it, but thanks
a lot for the explanation anyway! I'm just curious if the full path
would work in system() today. If it still would not work because
today's Windows is still like Windows 95 in this aspect, please ignore
my question and I will ask Microsoft for a refund.

Regards,
Yihui



On Mon, Oct 30, 2023 at 3:03 PM Prof Brian Ripley  wrote:
>
> On 30/10/2023 16:18, Yihui Xie wrote:
> > Hi,
> >
> > It may have been so for 20+ years but I just discovered today that system()
> > would always try to use the short path of a command on Windows:
> > https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
> > that's true, I wonder if it could provide an option to disable this
> > behavior, because we recently ran into a case in which short paths wouldn't
> > work. I wonder what the original motivation of using short paths was. If it
> > was to avoid spaces in paths, wouldn't shQuote() work? Thanks!
>
> No: system on Windows does not use a shell.
>
> The 'original motivation' was to work reliably!  Back in the days of
> Windows 95 when many parts of Windows only supported 8+3 names.
>
> >
> > Regards,
> > Yihui
> >
> >   [[alternative HTML version deleted]]
>
> Please do re-read the posting guide.  It has ' been so for 20+ years '.

My apologies! Sometimes I forget to switch to the plain-text mode when
writing to R mailing lists.

> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>

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

Re: [Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

Sure. I'm not sure if it's possible to make it easier to reproduce, but for
now the example would require installing TinyTeX (via
tinytex::install_tinytex(), which can be later uninstalled cleanly via
tinytex::uninstall_tinytex() after you finish the investigation). Then run:

  system2('fmtutil-sys', '--all')
  # or tinytex:::fmtutil() if fmtutil-sys.exe is not on PATH

and TeX Live would throw an error like this:

  ...\username\AppData\Roaming\TinyTeX\bin\windows\runscript.tlu:864: no
appropriate script or program found: fmtuti~1

The command "fmtutil-sys" is longer than 8 characters and hence shortened
to "fmtutil~1". Yes, in principle, TeX Live should work with short path
names, but it doesn't at the moment. I haven't figured out if it was a
recent breakage in TeX Live or not (I've tried to contact TeX Live
developers).

BTW, shell('fmtutil-sys --all') works fine.

Regards,
Yihui
--
https://yihui.org


On Mon, Oct 30, 2023 at 12:34 PM Tomas Kalibera 
wrote:

>
> On 10/30/23 17:18, Yihui Xie wrote:
> > Hi,
> >
> > It may have been so for 20+ years but I just discovered today that
> system()
> > would always try to use the short path of a command on Windows:
> > https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
> > that's true, I wonder if it could provide an option to disable this
> > behavior, because we recently ran into a case in which short paths
> wouldn't
> > work. I wonder what the original motivation of using short paths was. If
> it
> > was to avoid spaces in paths, wouldn't shQuote() work? Thanks!
>
> Could you please file a minimal reproducible example that exhibits the
> problem caused by an attempt to translate to short path names (note
> there is a fallback to long path names)? In principle, short path names
> should work when they are returned by Windows, this should not be
> causing any trouble.
>
> Thanks
> Tomas
>
> >
> > Regards,
> > Yihui
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > 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

[Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

Hi,

It may have been so for 20+ years but I just discovered today that system()
would always try to use the short path of a command on Windows:
https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
that's true, I wonder if it could provide an option to disable this
behavior, because we recently ran into a case in which short paths wouldn't
work. I wonder what the original motivation of using short paths was. If it
was to avoid spaces in paths, wouldn't shQuote() work? Thanks!

Regards,
Yihui

[[alternative HTML version deleted]]

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

Re: [Rd] R-4.3 version list.files function could not work correctly in chinese

[Yihui Xie]

Yes, I participated in the discussion. Basically dir() failed to list all
files since R 4.3.0 when filenames start with Chinese characters. I don't
have a Windows machine to test it, but this might be a minimal reproducible
example:

file.create("常用代码.R")
dir()

The OP said dir() would return "常用代码.R" in R.4.2.2 but not in R 4.3.0. In
the same discussion another person mentioned that the problem could also be
related to the file encoding, i.e., if the file content is encoded in
UTF-8, it could be recognized by dir(), but not in ANSI.

Regards,
Yihui
--
https://yihui.org


On Fri, Aug 11, 2023 at 6:25 AM Ivan Krylov  wrote:

> Dear 叶月光,
>
> Thank you for your message, but please follow the posting guide in your
> future messages: https://www.r-project.org/posting-guide.html
> https://www.r-project.org/bugs.html
>
> I understand from your link that list.files() ends up skipping some
> Chinese filenames in R-4.3.1 (but not R-4.2.2) on Windows, but would you
> (or perhaps Yihui Xie who I see is also participating in the discussion)
> mind translating the rest of your findings into English? Have you been
> able to narrow down the problem to certain character ranges, for
> example?
>
> --
> Best regards,
> Ivan
>
> __
> 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] Undocumented change of dirname("C:/") on R-devel on Windows

[Yihui Xie]

Thanks a lot! I can confirm that it has been fixed indeed.

Regards,
Yihui



On Mon, Feb 27, 2023 at 1:14 PM Tomas Kalibera 
wrote:

>
> On 2/27/23 17:02, Yihui Xie wrote:
>
> Hi Tomas,
>
> There has been an R CMD check error with xfun and r-devel on Windows for a
> while:
> https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/xfun-00check.html
> Basically it means that the following would return TRUE before:
>
>   normalizePath('a/b', mustWork = FALSE) == normalizePath('./a/b',
> mustWork = FALSE)
>
> but it became FALSE at some point in r-devel. I think 'a/b' and './a/b`
> should be treated as the same path. Does that make sense? Thanks!
>
> Thanks a lot for spotting and reporting this, fixed in R-devel.
> Normalization of non-existent paths was broken.
>
> Best
> Tomas
>
>
> Regards,
> Yihui
> --
> https://yihui.org
>
>
> On Thu, Feb 23, 2023 at 11:44 PM Hiroaki Yutani 
> wrote:
>
>> I confirmed the revert fixed my failing test. Thanks!
>>
>> 2023年2月23日(木) 20:12 Hiroaki Yutani :
>>
>> > Thanks for the prompt response, I'll confirm it after the new R-devel
>> > binary is available.
>> > Also, thanks for the detailed explanation. I agree with you in general.
>> >
>> > > "/" in "C:/" is a path separator or not, and whether it is trailing or
>> > not
>> >
>> > It seems a Windows' path basically consists of two components; a drive
>> > specification (e.g., C:) and the directory structure within the drive.
>> What
>> > I learned today is that both "C:/" and "C:" are valid path
>> specifications,
>> > but refer to different locations; "C:" is not the root directory of the
>> > drive, but just a relative path [1]. So, I agree with you that the
>> basename
>> > of "C:/" should be "C:/". However, at the same time, I don't feel this
>> is
>> > worth a breaking change, so I think we can preserve the current (R
>> 4.2.2)
>> > behavior.
>> >
>> > [1]:
>> >
>> https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#apply-the-current-directory
>> >
>> > Best,
>> > Yutani
>> >
>> > 2023年2月23日(木) 17:15 Tomas Kalibera :
>> >
>> >>
>> >> On 2/23/23 03:27, Hiroaki Yutani wrote:
>> >> > Hi,
>> >> >
>> >> > I found dirname() behaves differently on R-devel on Windows. Since
>> I'm
>> >> not
>> >> > sure which behavior is right, let me ask here before filing this to
>> R's
>> >> > Bigzilla.
>> >> >
>> >> > On R 4.2.2., we get
>> >> >
>> >> >  > dirname("C:/")
>> >> >  [1] "C:/"
>> >> >
>> >> > However, on R-devel (r83888), we get
>> >> >
>> >> >  > dirname("C:/")
>> >> >  [1] "."
>> >> >
>> >> > ?dirname says 'dirname returns the part of the path up to but
>> excluding
>> >> the
>> >> > last path separator, or "." if there is no path separator,' but I
>> don't
>> >> see
>> >> > how the root path is supposed to be treated based on this rule (,
>> >> whether
>> >> > it's WIndows or UNIX-alike).
>> >> Thanks for spotting the difference, I've reverted to the previous
>> >> behavior, the change was unintentional. If you spot any other
>> suspicious
>> >> changes in behavior in file-system operations, please report.
>> >> > What should we expect as the return value of dirname("C:/")? I feel
>> the
>> >> > current behavior on R 4.2.2 is right, but I'd like to confirm.
>> >>
>> >> I also think the old behavior is better, even though it could be argued
>> >> whether the "/" in "C:/" is a path separator or not, and whether it is
>> >> trailing or not. But the behavior is in line with Unix where dirname of
>> >> "/" is also "/". Msys2 would return "C:".
>> >>
>> >> If  "/" in "C:/" is a path separator but not a trailing path separator,
>> >> then basename("C:/") should probably be "" and not "C:", and this would
>> >> be in line with what R does on Unix. However, to be in line with Unix,
>> I
>> >> think the basename of "C:/" should be "C:/". Yet, Msys2 returns "C:"
>> >> which is what R does now.
>> >>
>> >> So what these functions should do on Windows is definitely tricky. In
>> >> either case the behavior is now again as in R 4.2.2.
>> >>
>> >> Best
>> >> Tomas
>> >>
>> >> >
>> >> > Best,
>> >> > Yutani
>> >> >
>> >> >   [[alternative HTML version deleted]]
>> >> >
>> >> > __
>> >> > 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
>>
>

[[alternative HTML version deleted]]

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

Re: [Rd] Undocumented change of dirname("C:/") on R-devel on Windows

[Yihui Xie]

Hi Tomas,

There has been an R CMD check error with xfun and r-devel on Windows for a
while:
https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/xfun-00check.html
Basically it means that the following would return TRUE before:

  normalizePath('a/b', mustWork = FALSE) == normalizePath('./a/b', mustWork
= FALSE)

but it became FALSE at some point in r-devel. I think 'a/b' and './a/b`
should be treated as the same path. Does that make sense? Thanks!

Regards,
Yihui
--
https://yihui.org


On Thu, Feb 23, 2023 at 11:44 PM Hiroaki Yutani 
wrote:

> I confirmed the revert fixed my failing test. Thanks!
>
> 2023年2月23日(木) 20:12 Hiroaki Yutani :
>
> > Thanks for the prompt response, I'll confirm it after the new R-devel
> > binary is available.
> > Also, thanks for the detailed explanation. I agree with you in general.
> >
> > > "/" in "C:/" is a path separator or not, and whether it is trailing or
> > not
> >
> > It seems a Windows' path basically consists of two components; a drive
> > specification (e.g., C:) and the directory structure within the drive.
> What
> > I learned today is that both "C:/" and "C:" are valid path
> specifications,
> > but refer to different locations; "C:" is not the root directory of the
> > drive, but just a relative path [1]. So, I agree with you that the
> basename
> > of "C:/" should be "C:/". However, at the same time, I don't feel this is
> > worth a breaking change, so I think we can preserve the current (R 4.2.2)
> > behavior.
> >
> > [1]:
> >
> https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#apply-the-current-directory
> >
> > Best,
> > Yutani
> >
> > 2023年2月23日(木) 17:15 Tomas Kalibera :
> >
> >>
> >> On 2/23/23 03:27, Hiroaki Yutani wrote:
> >> > Hi,
> >> >
> >> > I found dirname() behaves differently on R-devel on Windows. Since I'm
> >> not
> >> > sure which behavior is right, let me ask here before filing this to
> R's
> >> > Bigzilla.
> >> >
> >> > On R 4.2.2., we get
> >> >
> >> >  > dirname("C:/")
> >> >  [1] "C:/"
> >> >
> >> > However, on R-devel (r83888), we get
> >> >
> >> >  > dirname("C:/")
> >> >  [1] "."
> >> >
> >> > ?dirname says 'dirname returns the part of the path up to but
> excluding
> >> the
> >> > last path separator, or "." if there is no path separator,' but I
> don't
> >> see
> >> > how the root path is supposed to be treated based on this rule (,
> >> whether
> >> > it's WIndows or UNIX-alike).
> >> Thanks for spotting the difference, I've reverted to the previous
> >> behavior, the change was unintentional. If you spot any other suspicious
> >> changes in behavior in file-system operations, please report.
> >> > What should we expect as the return value of dirname("C:/")? I feel
> the
> >> > current behavior on R 4.2.2 is right, but I'd like to confirm.
> >>
> >> I also think the old behavior is better, even though it could be argued
> >> whether the "/" in "C:/" is a path separator or not, and whether it is
> >> trailing or not. But the behavior is in line with Unix where dirname of
> >> "/" is also "/". Msys2 would return "C:".
> >>
> >> If  "/" in "C:/" is a path separator but not a trailing path separator,
> >> then basename("C:/") should probably be "" and not "C:", and this would
> >> be in line with what R does on Unix. However, to be in line with Unix, I
> >> think the basename of "C:/" should be "C:/". Yet, Msys2 returns "C:"
> >> which is what R does now.
> >>
> >> So what these functions should do on Windows is definitely tricky. In
> >> either case the behavior is now again as in R 4.2.2.
> >>
> >> Best
> >> Tomas
> >>
> >> >
> >> > Best,
> >> > Yutani
> >> >
> >> >   [[alternative HTML version deleted]]
> >> >
> >> > __
> >> > 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] New URL redirect checks

[Yihui Xie]

Me too. I have changed some valid URLs in \url{} to \verb{} just to
avoid these check NOTEs. I do appreciate the check for the validity of
URLs in packages, especially those dead links (404), but discouraging
URLs with status code other than 200 (such as 301) feels like
overdoing the job. After I "hide" links from R CMD check with \verb{}
, it will be hard to know if these links are still valid in the
future.

Regards,
Yihui

On Tue, Sep 22, 2020 at 1:17 PM Kevin Wright  wrote:
>
> Isn't the whole concept of DOI basically link-shortening/redirecting?
>
> For example, this link
> https://doi.org/10.2134/agronj2016.07.0395
> redirects to
> https://acsess.onlinelibrary.wiley.com/doi/abs/10.2134/agronj2016.07.0395
>
> As a side note, I got so fed up with CRAN check complaints about (perfectly 
> valid) re-directs that I refuse to use the \url{} tag anymore.
>
> Kevin
>
>
> On Thu, Sep 17, 2020 at 8:32 AM Yihui Xie  wrote:
>>
>> I don't have an opinion on the URL shorteners, but how about the
>> original question? Redirection can be extremely useful in general.
>> Shortening URLs is only one of its possible applications. FWIW, CRAN
>> uses (303) redirect itself, e.g.,
>> https://cran.r-project.org/package=MASS is redirected to
>> https://cran.r-project.org/web/packages/MASS/index.html Should these
>> "canonical" CRAN links be disallowed in packages, too? Just as another
>> example, https://cran.r-project.org/bin/windows/base/release.html is
>> redirected to the latest Windows installer of R (through the 
>> tag).
>>
>> If the intent of the new URL redirect check is to disallow using URL
>> shorteners like bit.ly or nyti.ms, that may be fair, but it it is to
>> disallow using any URLs that are redirected, I think this CRAN policy
>> may be worth a reconsideration.
>>
>> Regards,
>> Yihui
>> --
>> https://yihui.org
>>
>>
>> On Thu, Sep 17, 2020 at 3:26 AM Gábor Csárdi  wrote:
>> >
>> > Right, I am sorry, I did not realize the security aspect here. I guess
>> > I unconsciously treated CRAN package authors as a trusted source.
>> >
>> > Thanks for the correction and clarification, and to CRAN for
>> > implementing these checks. :)
>> >
>> > G.
>> >
>> > On Wed, Sep 16, 2020 at 10:50 PM Duncan Murdoch
>> >  wrote:
>> > >
>> > > On 16/09/2020 4:51 p.m., Simon Urbanek wrote:
>> > > > I can't comment for CRAN, but generally, shorteners are considered 
>> > > > security risk so regardless of the 301 handling I think flagging those 
>> > > > is a good idea. Also I think it is particularly bad to use them in 
>> > > > manuals because it hides the target so the user has no idea what hey 
>> > > > will get.
>> > >
>> > > I agree, and we do have \href{}{} in Rd files and similar in other
>> > > formats for giving text of a link different than the URL if the URL is
>> > > inconveniently long.  There's still a bit of a security issue though:
>> > > the built in help browser (at least in MacOS) doesn't show the full URL
>> > > when you hover over the link, as most browsers do.  So one could have
>> > >
>> > > \href{https://disney.org}{https://horrible.web.site}
>> > >
>> > > Duncan Murdoch
>> > >
>> > >
>> > > >
>> > > > Cheers,
>> > > > Simon
>> > > >
>> > > >
>> > > >> On Sep 17, 2020, at 5:35 AM, Gábor Csárdi  
>> > > >> wrote:
>> > > >>
>> > > >> Dear all,
>> > > >>
>> > > >> the new CRAN URL checks flag HTTP 301 redirects. While I understand
>> > > >> the intent, I think this is unfortunate, because several URL shortener
>> > > >> services use 301 redirects, and often a shorter URL is actually better
>> > > >> in a manual page than a longer one that can be several lines long in
>> > > >> the console and also potentially truncated in the PDF manual.
>> > > >>
>> > > >> Some example shorteners that are flagged:
>> > > >>
>> > > >>> db <- tools:::url_db(c("https://nyti.ms";, 
>> > > >>> "https://t.co/mtXLLfYOYE";), "README")
>> > > >>> tools:::check_url_db(db)
>> > > >> URL: https://nyti.ms (moved to https://www.nytimes.com/)
>> > &g

Re: [Rd] New URL redirect checks

[Yihui Xie]

I don't have an opinion on the URL shorteners, but how about the
original question? Redirection can be extremely useful in general.
Shortening URLs is only one of its possible applications. FWIW, CRAN
uses (303) redirect itself, e.g.,
https://cran.r-project.org/package=MASS is redirected to
https://cran.r-project.org/web/packages/MASS/index.html Should these
"canonical" CRAN links be disallowed in packages, too? Just as another
example, https://cran.r-project.org/bin/windows/base/release.html is
redirected to the latest Windows installer of R (through the 
tag).

If the intent of the new URL redirect check is to disallow using URL
shorteners like bit.ly or nyti.ms, that may be fair, but it it is to
disallow using any URLs that are redirected, I think this CRAN policy
may be worth a reconsideration.

Regards,
Yihui
--
https://yihui.org


On Thu, Sep 17, 2020 at 3:26 AM Gábor Csárdi  wrote:
>
> Right, I am sorry, I did not realize the security aspect here. I guess
> I unconsciously treated CRAN package authors as a trusted source.
>
> Thanks for the correction and clarification, and to CRAN for
> implementing these checks. :)
>
> G.
>
> On Wed, Sep 16, 2020 at 10:50 PM Duncan Murdoch
>  wrote:
> >
> > On 16/09/2020 4:51 p.m., Simon Urbanek wrote:
> > > I can't comment for CRAN, but generally, shorteners are considered 
> > > security risk so regardless of the 301 handling I think flagging those is 
> > > a good idea. Also I think it is particularly bad to use them in manuals 
> > > because it hides the target so the user has no idea what hey will get.
> >
> > I agree, and we do have \href{}{} in Rd files and similar in other
> > formats for giving text of a link different than the URL if the URL is
> > inconveniently long.  There's still a bit of a security issue though:
> > the built in help browser (at least in MacOS) doesn't show the full URL
> > when you hover over the link, as most browsers do.  So one could have
> >
> > \href{https://disney.org}{https://horrible.web.site}
> >
> > Duncan Murdoch
> >
> >
> > >
> > > Cheers,
> > > Simon
> > >
> > >
> > >> On Sep 17, 2020, at 5:35 AM, Gábor Csárdi  wrote:
> > >>
> > >> Dear all,
> > >>
> > >> the new CRAN URL checks flag HTTP 301 redirects. While I understand
> > >> the intent, I think this is unfortunate, because several URL shortener
> > >> services use 301 redirects, and often a shorter URL is actually better
> > >> in a manual page than a longer one that can be several lines long in
> > >> the console and also potentially truncated in the PDF manual.
> > >>
> > >> Some example shorteners that are flagged:
> > >>
> > >>> db <- tools:::url_db(c("https://nyti.ms";, "https://t.co/mtXLLfYOYE";), 
> > >>> "README")
> > >>> tools:::check_url_db(db)
> > >> URL: https://nyti.ms (moved to https://www.nytimes.com/)
> > >> From: README
> > >> Status: 200
> > >> Message: OK
> > >>
> > >> URL: https://t.co/mtXLLfYOYE (moved to
> > >> https://www.bbc.co.uk/news/blogs-trending-47975564)
> > >> From: README
> > >> Status: 200
> > >> Message: OK
> > >>
> > >> __
> > >> 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] Possible Bug: file.exists() Function. Due to UTF-8 Encoding differences on Windows between R 4.0.1 and R 3.6.3?

[Yihui Xie]

Hi Tomas,

Sorry for the false alarm! I did some further testing, and you were
right. There was no regression. I suspected it was a regression
because the user who reported the issue said his code worked in R 3.6
but not 4.0. I should have tested it more carefully by myself. After I
tested it again with the German locale and Chinese locale,
respectively, I found that the code worked for both versions of R in
the German locale, and failed in the Chinese locale. Your explanation
makes perfect sense to me. I have also read your blog post when it
came out last month, and I'm really looking forward to the end of this
character encoding pain! Thank you very much for the hard work!

Regards,
Yihui
--
https://yihui.org

On Mon, Jun 22, 2020 at 3:37 AM Tomas Kalibera  wrote:
>
> Hi Yihui,
>
> list.files() returns file names converted to native encoding by Windows,
> so one needs to use only characters representable in current native
> encoding for file names. If one wants to be safe, it makes sense to be
> much stricter than that (only ASCII, and only a subset of it, there is a
> number of recommendations that can be found online). Using more than
> that is asking for trouble.
>
> Unicode "\u00e4" is a Latin-1 character, so representable in CP1252. On
> my Windows running in CP1252 as C locale and system code page, your
> example works fine, file.exists() returns TRUE, and this is the expected
> behavior (tested in R-devel and R4.0).
>
> Your example was run in CP1252 as C locale but CP936 as the system code
> page (see the sessionInfo() output). On Windows, unfortunately, there
> are two different "current locales" at a time. With your settings
> (CP1252 as C locale and CP936 as system code page), I get the same
> results as you, file.exists() returns FALSE. enc2native(z) works fine
> and returns a valid Latin-1 string, but that is because here "native" is
> CP1252. Windows API functions and consequently some C library functions
> that return strings from the OS, however, convert to the encoding from
> the system code page, which is CP936 and it cannot represent "ä". So,
> currently the behavior you are reporting is expected for R 4.0 and
> earlier. I don't think this is a regression, it couldn't have worked
> before, either - and I've tested in 3.6.3 and 3.4.3 on my system.
>
> These problems will go away when UTF-8 is both the current native
> encoding for the C locale and the system code page. This is possible in
> recent Windows 10, but requires UCRT and hence a new toolchain to build
> R, and requires all packages and libraries to be rebuilt from source.
> More details on my blog, also there is experimental build of R
> (installer) and experimental toolchain available:
> https://developer.r-project.org/Blog/public/2020/05/02/utf-8-support-on-windows/index.html
>
> Best
> Tomas
>
>
> On 6/22/20 6:11 AM, Yihui Xie wrote:
> > Hi Tomas,
> >
> > I received a report about R 4.0.0 in the knitr package
> > (https://github.com/yihui/knitr/issues/1840), and I think it is
> > related to the issue here. I created a minimal reproducible example
> > below:
> >
> > owd = setwd(tempdir())
> > z = 'K\u00e4sch.txt'
> > file.create(z)
> > list.files()
> > file.exists(list.files())
> > setwd(owd)
> >
> > Output:
> >
> >> owd = setwd(tempdir())
> >> z = 'K\u00e4sch.txt'
> >> file.create(z)
> > [1] TRUE
> >> list.files()
> > [1] "K?sch.txt"
> >> file.exists(list.files())
> > [1] FALSE
> >> setwd(owd)
> > I wonder if it is expected that file.exists() returns FALSE here.
> >
> >> sessionInfo()
> > R version 4.0.1 (2020-06-06)
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > Running under: Windows 7 x64 (build 7601) Service Pack 1
> >
> > locale:
> > [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United 
> > States.1252
> > [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
> > [5] LC_TIME=English_United States.1252
> > system code page: 936
> >
> > FWIW, I also tested Chinese characters in the variable `z` above, and
> > file.exists() returns TRUE only after I Sys.setlocale(, "Chinese").
> >
> > Regards,
> > Yihui
> >
> > On Thu, Jun 11, 2020 at 3:11 AM Tomas Kalibera  
> > wrote:
> >>
> >> Dear Juan,
> >>
> >> I don't see what is the problem from your report. Please try to create a
> >> minimal but complete reproducible example that does not use the renv
> >> package. Perhaps you could use the R debugger (e.g. via
> >> options(

Re: [Rd] Possible Bug: file.exists() Function. Due to UTF-8 Encoding differences on Windows between R 4.0.1 and R 3.6.3?

[Yihui Xie]

Hi Tomas,

I received a report about R 4.0.0 in the knitr package
(https://github.com/yihui/knitr/issues/1840), and I think it is
related to the issue here. I created a minimal reproducible example
below:

owd = setwd(tempdir())
z = 'K\u00e4sch.txt'
file.create(z)
list.files()
file.exists(list.files())
setwd(owd)

Output:

> owd = setwd(tempdir())
> z = 'K\u00e4sch.txt'
> file.create(z)
[1] TRUE
> list.files()
[1] "K?sch.txt"
> file.exists(list.files())
[1] FALSE
> setwd(owd)

I wonder if it is expected that file.exists() returns FALSE here.

> sessionInfo()
R version 4.0.1 (2020-06-06)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
system code page: 936

FWIW, I also tested Chinese characters in the variable `z` above, and
file.exists() returns TRUE only after I Sys.setlocale(, "Chinese").

Regards,
Yihui

On Thu, Jun 11, 2020 at 3:11 AM Tomas Kalibera  wrote:
>
>
> Dear Juan,
>
> I don't see what is the problem from your report. Please try to create a
> minimal but complete reproducible example that does not use the renv
> package. Perhaps you could use the R debugger (e.g. via
> options(error=recover)) to find out what is the argument that
> file.exists() has been called with. And then you could try just to call
> file.exists() directly with that argument to trigger the problem.
>
> It may be that the argument has been corrupted/is invalid in the current
> native encoding. If that is the case, the next step would be to find out
> who corrupted it (renv, R, something else). The error is displayed when
> a path name cannot be converted from the current native encoding to
> UTF16-LE.
>
> The experimental support for UTF-8 as native encoding on Windows 10 is
> only available in a custom build of R, like the one I linked from my
> blog post.
>
> Thanks
> Tomas
>
>
>
> On 6/10/20 1:06 PM, Juan Telleria Ruiz de Aguirre wrote:
> > Dear R Developers,
> >
> > I am having an issue with the renv package and R 4.0.1, which I
> > suspect is related to base R and not the renv package itself, as with
> > R 3.6.3 such an "error" does not appear.
> >
> > The error is raised by a file.exists() path, and path
> > "C:\Users\J-tel\Documents", which in R 3.6.3 is read correctly, but in
> > R 4.0.1 fails (Probably because of the "-" symbol), and I suspect it
> > might be related with the new UTF-8 usage on Windows 10?
> > (https://developer.r-project.org/Blog/public/2020/05/02/utf-8-support-on-windows/index.html)
> >
> > I have also checked file.exists() function and its internals, and seem
> > not to have happened changes in the meanwhile within them:
> >
> > https://github.com/wch/r-source/blob/0e3b3182f87a60af4b0293a5410dde680b910f49/src/library/base/R/files.R
> > https://github.com/search?q=SEXP%20attribute_hidden%20do_fileexists+repo:wch/r-source&type=Code
> >
> > Error Details:
> >
> >> renv::init()
> > Error in file.exists(children) :
> >file name conversion problem -- name too long?
> >> traceback()
> > 14: file.exists(children)
> > 13: renv_dependencies_find_dir_children(path, root)
> > 12: renv_dependencies_find_dir(path, root)
> > 11: FUN(X[[i]], ...)
> > 10: lapply(path, renv_dependencies_find_impl, root = root)
> > 9: renv_dependencies_find(path, root)
> > 8: (function (path = getwd(), root = NULL, ..., progress = TRUE,
> > errors = c("reported", "fatal", "ignored"), dev = FALSE)
> > {
> > path <- renv_path_normalize(path, winslash = "/", mustWork = TRUE)
> > root <- root %||% renv_dependencies_root(path)
> > if (exists(path, envir = `_renv_dependencies`))
> > return(get(path, envir = `_renv_dependencies`))
> > renv_dependencies_begin(root = root)
> > on.exit(renv_dependencies_end(), add = TRUE)
> > dots <- list(...)
> > if (identical(dots[["quiet"]], TRUE)) {
> > progress <- FALSE
> > errors <- "ignored"
> > }
> > files <- renv_dependencies_find(path, root)
> > deps <- renv_dependencies_discover(files, progress, errors)
> > renv_dependencies_report(errors)
> > deps
> > })(path, progress = FALSE, errors = errors, dev = TRUE)
> > 7: eval(call, envir = parent.frame(2))
> > 6: eval(call, envir = parent.frame(2))
> > 5: delegate(renv_dependencies_impl)
> > 4: dependencies(path, progress = FALSE, errors = errors, dev = TRUE)
> > 3: withCallingHandlers(dependencies(path, progress = FALSE, errors = errors,
> > dev = TRUE), renv.dependencies.error =
> > renv_dependencies_error_handler(message,
> > errors))
> > 2: renv_dependencies_scope(project, action = "init")
> > 1: renv::init()
> >
> >> renv::diagnostics()
> > Diagnostics Report -- renv [0.10.0]
> > ===
> >
> > # Session Info ===

Re: [Rd] [External] Re: quiet namespace load is noisy

[Yihui Xie]

I mentioned the same thing a couple of months ago but didn't get a
response: https://stat.ethz.ch/pipermail/r-devel/2019-May/04.html

In your case of package vignettes, it is easy enough to suppress the
messages via the knitr chunk option message = FALSE. However, I still
wonder if it will be a better idea if requireNamespace(quietly = TRUE)
can suppress such messages, because in the past, we can test if a
package is loadable via

  if (requireNamespace(pkg, quietly = TRUE)) { ... }

And now we have to use suppressMessages() or
suppressPackageStartupMessages() plus quietly = TRUE:

  if (suppressPackageStartupMessages(requireNamespace(pkg, quietly =
TRUE))) { ... }

I'm aware of the fact that if a package has packageStartupMessage() in
its .onLoad(), requireNamespace(quietly = TRUE) won't suppress such
messages, and we still have use suppressPackageStartupMessages(). This
statement in Russ's post was incorrect:

> After all, other package startup messages ARE suppressed

but I feel it is a nice feature request for quietly = TRUE to call
suppressPackageStartupMessages() automatically.

Regards,
Yihui
--
https://yihui.name

On Tue, Jul 23, 2019 at 9:29 AM Henrik Singmann  wrote:
>
> Dear Russ,
>
> I had the same problem in my vignettes and setting both message and warning
> to FALSE seems to remove all unwanted output:
>
> ```{r message=FALSE, warning=FALSE}
> library("afex")
> library("ggplot2")
> library("cowplot")
> theme_set(theme_grey())
> ```
>
> Result:
> https://cran.r-project.org/web/packages/afex/vignettes/afex_plot_introduction.html
>
> Best,
> Henrik
>
>
> Am Di., 23. Juli 2019 um 14:52 Uhr schrieb Ben Bolker :
>
> >
> >   Does setting message=FALSE in the chunk options of the vignette help?
> >
> >   Or less preferably, using supressMessages() ?
> >
> > On 2019-07-23 9:36 a.m., Lenth, Russell V wrote:
> > > Lionel,
> > >
> > > Thanks for your response. I understand that method overriding can be a
> > serious issue, but as you say, this is not something that the user can act
> > upon. Yet the message lands at the user’s feet.
> > >
> > > In my case, the messages are cluttering my package vignettes, and may or
> > may not represent what users see if they themselves run the vignette code,
> > depending on what version of ggplot2, etc. they have. I will certainly
> > update my ggplot2 installation and that will help. But basically I don’t
> > ever want these kinds of messages to appear in my vignettes, so I will seek
> > some other workaround.
> > >
> > > Russ
> > >
> > > Sent from my iPhone
> > >
> > >> On Jul 23, 2019, at 1:32 AM, Lionel Henry  wrote:
> > >>
> > >> Hello,
> > >>
> > >> I think `quietly` should only silence normal masking messages
> > >> intended for users and providing information about normal
> > >> behaviour, such as masking.  This is not the case here as the
> > >> message is about overriding of S3 methods, which has global
> > >> effect and is rather problematic. It may change behaviour of
> > >> package and script code in unpredictable ways.
> > >>
> > >> This is not something that the user can act upon, the developers
> > >> of the parties involved need to be contacted by users so they can
> > >> fix it (the developers of the conflicting methods might not be
> > >> aware if the generic is from a third party package, such as
> > >> base::print()). In the case of ggplot2 vs rlang, you can update
> > >> ggplot2 to the latest version to fix these messages.
> > >>
> > >>> After all, other package startup messages ARE suppressed, and
> > >>> even error messages are suppressed
> > >>
> > >> Note that `quietly = TRUE` does not really suppress error
> > >> messages for missing packages. The errors are converted to a
> > >> boolean return value, and thus become normal behaviour, for which
> > >> it makes sense to suppress the message. This does not imply the
> > >> S3 overriding message should be suppressed as well.
> > >>
> > >> Best,
> > >> Lionel
> > >>
> > >>
> > >>> On 23 Jul 2019, at 06:29, Lenth, Russell V 
> > wrote:
> > >>>
> > >>> Dear R-devel,
> > >>>
> > >>> Consider the following clip (in R version 3.6.0, Windows):
> > >>>
> >  requireNamespace("ggplot2", quietly = TRUE)
> > >>>   Registered S3 methods overwritten by 'ggplot2':
> > >>> method from
> > >>> [.quosures rlang
> > >>> c.quosures rlang
> > >>> print.quosures rlang
> > >>>
> > >>> It seems to me that if one specifies 'quietly = TRUE', then messages
> > about S3 method overrides should be quieted along with everything else.
> > After all, other package startup messages ARE suppressed, and even error
> > messages are suppressed:
> > >>>
> >  requireNamespace("xyz", quietly = TRUE)
> >  ## (it is silent even though there is no "xyz" package)
> > >>>
> > >>> Thanks
> > >>>
> > >>> Russ Lenth
> > >>> U of Iowa
> > >>>
> > >>> __
> > >>> R-devel@r-project.org mailing list
> > >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

[Rd] Should requireNamespace(quietly = TRUE) suppress messages about overwritten S3 methods?

[Yihui Xie]

Hi,

In the NEWS of R 3.6.0:

> When loading namespaces, S3 method registrations which overwrite previous 
> registrations are now noted by default (using packageStartupMessage()).

As a result, requireNamespace() with R 3.6.0 is no longer quiet as before, e.g.,

> requireNamespace('ggplot2', quietly = TRUE)
Registered S3 methods overwritten by 'ggplot2':
  method from
  [.quosures rlang
  c.quosures rlang
  print.quosures rlang

I wonder if this is intentional. Thanks!

Regards,
Yihui
--
https://yihui.name

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

Re: [Rd] R 3.5.3 and 3.6.0 alpha Windows bug: UTF-8 characters in code are simplified to wrong ones

[Yihui Xie]

Since it is "technically easy" to disable the best fit conversion and
the best fit is rarely good, how about providing an option for
code/package authors to disable it? I'm asking because this is one of
the most painful issues in packages that may need to source() code
containing UTF-8 characters that are not representable in the Windows
native encoding. Examples include knitr/rmarkdown and shiny. Basically
users won't be able to knit documents or run Shiny apps correctly when
the code contains characters that cannot be represented in the native
encoding.

Regards,
Yihui
--
https://yihui.name

On Wed, Apr 10, 2019 at 6:36 AM Tomas Kalibera  wrote:
>
> On 4/10/19 1:14 PM, Jeroen Ooms wrote:
> > On Wed, Apr 10, 2019 at 12:19 PM Tomáš Bořil  wrote:
> >> Minimalistic example:
> >> Let's type "ř" (LATIN SMALL LETTER R WITH CARON) in RGui console:
> >>> "ř"
> >> [1] "r"
> >>
> >> Although the script is in UTF-8, the characters are replaced by
> >> "simplified" substitutes uncontrollably (depending on OS locale). The
> >> same goes with simply entering the code statements in R Console.
> >>
> >> The problem does not occur on OS with UTF-8 locale (Mac OS, Linux...)
> > I think this is a "feature" of win_iconv that is bundled with base R
> > on Windows (./src/extra/win_iconv). The character from your example is
> > not part of the latin1 (iso-8859-1) set, however, win-iconv seems to
> > do so anyway:
> >
> >> x <- "\U00159"
> >> print(x)
> > [1] "ř"
> >> iconv(x, 'UTF-8', 'iso-8859-1')
> > [1] "r"
> >
> > On MacOS, iconv tells us this character cannot be represented as latin1:
> >
> >> x <- "\U00159"
> >> print(x)
> > [1] "ř"
> >> iconv(x, 'UTF-8', 'iso-8859-1')
> > [1] NA
> >
> > I'm actually not sure why base-R needs win_iconv (but I'm not an
> > encoding expert at all). Perhaps we could try to unbundle it and use
> > the standard libiconv provided by the Rtools toolchain bundle to get
> > more consistent results.
>
> win_iconv just calls into Windows API to do the conversion, it is
> technically easy to disable the "best fit" conversion, but I think it
> won't be a good idea. In some cases, perhaps rare, the best fit is good,
> actually including the conversion from "ř" to "r" which makes perfect
> sense. But more importantly, changing the behavior could affect users
> who expect the substitution to happen because it has been happening for
> many years, and it won't help others much.
>
> Tomas
>
> >
> > __
> > 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

[Rd] Inconsistent returned values of normalizePath(NA_character_) on Windows and *nix

[Yihui Xie]

Hi,

I just noticed normalizePath(NA_character_) returns NA_character_ on
*nix but "%HOME%\\NA" on Windows (with a warning by default), where
%HOME% denotes the HOME folder like "C:\\Users\\John". I'm not sure if
this is a bug or by design.

Regards,
Yihui
--
https://yihui.name

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

Re: [Rd] Parametrized Vignettest in R packages

[Yihui Xie]

I wonder if get(data(foo, package="myPackage")) could be rewritten as
myPackage::foo. The latter will be a little more rigorous, because
data(foo) simply returns a character string "foo", so you are
essentially calling get ("foo"), and the default get(, inherits =
FALSE) may cause you trouble sometimes.

Anyway, the value returned by quote() can be represented when calling
dput(), so knitr can support it when generating the R script from the
vignette.

Another way to specify the params defaults could be:

---
params:
  foo: null
---

```{r}
if (is.null(params$foo)) params$foo = myPackage::foo
```

Regards,
Yihui
--
https://yihui.name


On Mon, Jul 9, 2018 at 3:11 PM, Witold E Wolski  wrote:
> Dear Duncan,
>
> Was close to giving up to use the parameterized rmarkown as vignettes.
> But your suggestions to use quote and eval, as well as to use the
> package parameter in data
>  made it work, with all devtools::install,check,build and
> build_vignettes as well as with R CMD ... etc.
> But most importantly it also still works with:
> rmarkdown::render("vignettes/tr_srm_summary.Rmd",
> params=list(configuration=skylineconfig, data=sample_analysis))
>
> THANK YOU.
>
> This is how my vignette header looks (see below) and it works.
>
> ---
> title: "Titel"
> author: "w...@fgcz.ethz.ch"
> date: "`r Sys.Date()`"
> output:
>   pdf_document: default
>   html_document: default
> params:
>   configuration:  !r quote(get(data(skylineconfig, package="myPackage")))
>   data: !r quote(get(data(sample_analysis, package="myPackage")))
> vignette: >
>   %\VignetteIndexEntry{Summarize Peptide Level Measurements}
>   %\VignetteEngine{knitr::rmarkdown}
>   %\VignetteEncoding{UTF-8}
> ---
>
>
> ```{r setup, include=FALSE}
> library(tidyverse)
>
> knitr::opts_chunk$set(echo = FALSE, message=FALSE)
> data <- eval(params$data)
> configuration <- eval(params$configuration)
> ```
>
> Have a great evening.
>
> regards
> Witek
>
> On 9 July 2018 at 21:32, Duncan Murdoch  wrote:
>> On 09/07/2018 3:24 PM, Witold E Wolski wrote:
>>>
>>> Dear Yihui,
>>>
>>> Thank you for the valuable questions.
>>>
>>> sample_analysis is a "tibble" while
>>> configuration is an "R6" class.
>>> But I also have parametrized reports where I pass R reference classes
>>> as arguments.
>>>
>>> This is the Rmd yaml params part corresponding to the error message.
>>>
>>> params:
>>>configuration:  !r get(data(skylineconfig))
>>>data: !r get(data(sample_analysis))
>>>
>>> Might the R6 class which I pass to  configuration the source of the
>>> problem here? I have heard somewhere that R6 uses environments to
>>> implemented some features.
>>>
>>>
>>>
>>> There is also a further problem I am encountering reproducible when
>>> running devtools::install() or R CMD INSTALL
>>>
>>> ** installing vignettes
>>> 'tr_srm_summary.Rmd' using 'UTF-8'
>>> Warning in data(skylineconfig) : data set 'skylineconfig' not found
>>> Error in get(data(skylineconfig)) : object 'skylineconfig' not found
>>
>>
>> You likely need to specify the package name, e.g.
>>
>> data("skylineconfig", package = "yourpackage")
>>
>> Also see my suggestion to use quote() to delay evaluation:
>>
>>
>>> params:
>>>configuration:  !r quote(get(data(sample_analysis)))
>>>
>>> in the YAML will set configuration to the expression needed to get the
>>> environment;
>>>
>>>  eval(params$configuration)
>>
>>
>> Duncan Murdoch
>
>
>
> --
> Witold Eryk Wolski

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

Re: [Rd] Parametrized Vignettest in R packages

[Yihui Xie]

So far you haven't provided a reproducible example yet. I wonder what
exactly the object `sample_analysis` is. Sounds like it is an
environment. If that is the case, devtools::build_vignettes() will
tangle (for the meaning of "tangle", see ?tools::buildVignette) your
vignette into an invalid R script. Environments cannot be represented
via dput(), so knitr's purl() (eventually called by the vignette
engine) cannot really create a valid R script when your vignette
contains `params` that uses environment values. Most other types of
values should be fine.

Regards,
Yihui
--
https://yihui.name


On Mon, Jul 9, 2018 at 10:37 AM, Duncan Murdoch
 wrote:
> On 09/07/2018 8:49 AM, Witold E Wolski wrote:
>>
>> Dear Duncan,
>>
>> Following your advice (Thank you for it) I did include into the vignettes
>> params:
>>configuration: !r get(data(sample_analysis))
>>data: !r get(data(skylineconfig))
>>
>> And everything seemed (see below) to work fine.
>> devtools::build_vignettes() builds the vignettes.
>>
>> Runs with NO error. By this the .Rmd file, html file and corresponding
>> .R files is being placed into the inst/doc directory.
>>
>> However, when I did want to check the package by running
>> devtools::check(build_args="--no-build-vignettes")
>>
>> The following warning is shown:
>>
>> Warning: parse error in file
>>
>> 'C:/Users/wolski/AppData/Local/Temp/Rtmp4QanHv/SRMService.Rcheck/SRMService/doc/tr_srm_summary.R':
>>
>> /Users/wolski/AppData/Local/Temp/Rtmp4QanHv/SRMService.Rcheck/SRMService/doc/tr_srm_summary.R:2:22:
>> unexpected '<'
>> 1: params <-
>> 2: list(configuration = <
>>
>> This is how the start of the .R file produced from the vignette looks
>> like.
>>
>> params <-
>> list(configuration = , data = structure(list(protein_Id =
>> c("CiRT standards",
>>
>> I am worried that this is the end of this road with parameterized
>> vignettes then? What do you think?
>
>
> Interesting.  The issue is that the value being assigned to configuration is
> an environment, and whatever code produces those lines in tr_srm_summary.R
> isn't deparsing it into something parseable.  (This isn't a big surprise:
> dput and deparse both fail at that.)
>
> I'd guess a solution is not to save sample_analysis as an environment, but
> maybe you didn't know you were doing that since some other structures are
> implemented as environments.
>
> Perhaps you could use
>
> configuration: !r as.list(get(data(sample_analysis)))
>
> and then when you need to use it, convert it back to the original type?
>
> Duncan Murdoch
>>
>>
>> regards
>> Witek
>>
>>
>>
>>
>>
>> On 2 July 2018 at 18:21, Duncan Murdoch  wrote:
>>>
>>> On 02/07/2018 11:22 AM, Witold E Wolski wrote:


 Hello,

 Thank you for the questions as well as remaining me of the default
 parameters in the yaml session.
 Indeed this seems to be the solution.


 But how would I assign package data as a default parameter?
 So originally I thought to render the markdown with :

 
 data(sample_analysis)
 data(skylineconfig)
 x <- rmarkdown::render("report.Rmd", output_format = "html_document",
 params = list(data = sample_analysis,
   configuration =
 skylineconfig),envir = new.env())
 

 I do not think I can write:

 params:
 configuration: !r data(sample_analysis)
 data: !r data(skylineconfig)

 since data does not return the package just puts them in the env as a
 side effect. Is there a different base function to achieve it.
>>>
>>>
>>>
>>> I think you could use
>>>
>>>   params:
>>>configuration: !r get(data(sample_analysis))
>>>data: !r get(data(skylineconfig))
>>>
>>> but if that doesn't work, a longer version is
>>>
>>>   params:
>>>configuration: !r {data(sample_analysis); sample_analysis}
>>>data: !r {data(skylineconfig); skylineconfig}
>>>
>>> Duncan Murdoch
>>>
>>>


 Thank you
 Witek




 On 2 July 2018 at 16:56, Duncan Murdoch 
 wrote:
>
>
> On 02/07/2018 10:30 AM, Witold E Wolski wrote:
>>
>>
>>
>> Hello,
>>
>> I have a package which includes some parameterized r-markdown report
>> which I would also like to build as package vignettes.
>>
>> Is there a way to run the parameterized vignette creation with the
>> package build or package check?
>
>
>
>
>
> Doesn't the usual method work?  You can specify defaults for parameters
> in
> the YAML header; I'd expect those to be the parameter values that get
> used.
>
> You can give instructions to your users on how to rebuild the reports
> with
> different parameters.
>
> Duncan Murdoch
>
>>
>> Thank you
>>
>



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

Re: [Rd] Bug in RScript.exe for 3.5.0

[Yihui Xie]

It seems the fix has not been ported to the patched version of R on
Windows yet. I just tested R version 3.5.0 Patched (2018-04-27
r74667).

IMHO this bug is so bad that it is worth a new release R 3.5.1 before
it starts biting more users like this one
https://stackoverflow.com/q/50077412/559676. BTW, although the bug has
been fixed (https://github.com/wch/r-source/commit/c29f694), I think
it will be even better if a corresponding test is added at the same
time to prevent this from happening again in the future.

Thanks!

Yihui

On Fri, Apr 27, 2018 at 7:03 AM, Kerry Jackson  wrote:
>
> Thanks Tomas,
>
> I confirm the R Under development (unstable) (2018-04-26 r74651) version 
> works for Rscript when the file name has a space, and no arguments are 
> specified.
>
> C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" "C:\foo bar.R"
> R Under development (unstable) (2018-04-26 r74651)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.6.0
>
> C:\>
>
> -Original Message-
> From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
> Sent: Thursday, April 26, 2018 10:22 AM
> To: Kerry Jackson 
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
>
> Thanks, actually this is because the snapshot build is still one version 
> behind (74642, the fix is in 74643). When I build my own installer and 
> install it seems to be working fine. Sorry for the confusion,
>
> Tomas
>
> On 04/26/2018 02:49 PM, Kerry Jackson wrote:
> > Hi Tomas,
> >
> > Thanks for the info about the binary builds; I did install it, however the 
> > bug still seems to be there in the current build.  The workaround you 
> > suggested does work:
> >
> > C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" "C:\foo bar.R"
> > Fatal error: cannot open file 'C:\foo': No such file or directory
> >
> >
> > C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" --vanilla "C:\foo 
> > bar.R"
> > What do you get when you multiply 6 * 9?
> > C:\>
> >
> > -Original Message-
> > From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
> > Sent: Thursday, April 26, 2018 8:35 AM
> > To: Kerry Jackson ; r-devel@r-project.org
> > Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
> >
> > On 04/26/2018 02:23 PM, Kerry Jackson wrote:
> >> Thanks Tomas.
> >>
> >> I confirm the quick workaround works for me in the DOS prompt, and when 
> >> having a shortcut to RScript in SendTo, and when used in the Task 
> >> Scheduler.  I have not tested the R-devel version, due to my unfamiliarity 
> >> with installing from source code.
> > Thanks, Kerry.
> >
> > There are binary builds for daily snapshots of R-devel
> > (development/unstable version of R) at
> > https://cran.r-project.org/bin/windows/base/rdevel.html
> >
> > At this time the build should already have the fix.
> >
> > Best
> > Tomas
> >
> >> -Original Message-
> >> From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
> >> Sent: Thursday, April 26, 2018 6:34 AM
> >> To: Kerry Jackson ; r-devel@r-project.org
> >> Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
> >>
> >> Fixed in R-devel. I will port to R-patched after more testing.
> >> Tomas
> >>
> >> On 04/26/2018 01:52 AM, Tomas Kalibera wrote:
> >>> Thanks for the report. A quick workaround before this gets fixed is
> >>> to add an extra first argument that has no space in it, e.g.
> >>>
> >>> Rscript --vanilla "foo bar.R"
> >>>
> >>> The problem exists on all systems, not just Windows.
> >>>
> >>> Best
> >>> Tomas
> >>>
> >>> On 04/25/2018 09:55 PM, Kerry Jackson wrote:
>  Hi R Developers,
>  I have found what I think is a bug in the RScript.exe in version
>  3.5.0 of R for Windows.
>  When I call Rscript.exe for Version 3.5 of R, it is unable to open
>  the file if the file name or path has a space in it.
>  As an example of what happens, I saved 2 files with the code:
>  cat("What do you get when you multiply 6 * 9?") as C:\foo bar.R and
>  as C:\foo_bar.R When I in a DOS command window try to run these
>  using version 3.4.3 and 3.5:
>  C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo bar.R"
>  What do you get when you multiply 6 * 9?
>  C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo_bar.R"
>  What do you get when you multiply 6 * 9?
>  C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo bar.R"
>  Fatal error: cannot open file 'C:\foo': No such file or directory
> 
> 
>  C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo_bar.R"
>  What do you get when you multi

Re: [Rd] Best practices in developing package: From a single file

[Yihui Xie]

Similarly, I created this example a couple of years ago:
https://github.com/yihui/rlp which shows that you can create a package
from R Markdown documents (or any documents that knitr supports).
Basically you can start with an R Markdown document, and after
clicking a button in RStudio, you will get a full R package, with R
code, vignettes, and Rd (killing three birds with one stone). The
reason that you can get Rd is because of roxygen2.

I'm not interested in convincing Duncan of using roxygen (or
GIT/Github). It is fine that one loves or hates a tool. Just use tools
that make yourself comfortable. To me as a package developer, roxygen2
is indispensable (so are GIT/Github), and I use it in all my packages.
I had almost lost interest in developing R packages about 8 years ago
just because I found writing raw Rd extremely frustrating. Then
fortunately, roxygen was born, just in time.

Personally, it doesn't bother me if Duncan thinks roxygen-based
package documentations are typically of poor quality. I care a lot of
about documentation, and sometimes spend months after months on
documentation (Rd, vignettes, websites, and books). I'd very much like
to volunteer to have Duncan use any of my packages as examples of
"poor-quality roxygen-based documentation", and let's figure out why
they are poor (i.e., do we blame it on roxygen2 or myself?).

Regards,
Yihui
--
https://yihui.name


On Wed, Jan 31, 2018 at 8:51 AM, Pfaff, Bernhard Dr.
 wrote:
> Dear All:
>
> stepping in late, but @Joris, if you would like to take 'from a single file' 
> literally,
> have a look at:
>
> https://github.com/bpfaff/lp4rp
>
> (lp4rp: literate programming for R packages);
>
> Cheers,
> Bernhard
>
> ps:  incidentally, within the noweb-file roxygen is employed.
>
> -Ursprüngliche Nachricht-
> Von: R-devel [mailto:r-devel-boun...@r-project.org] Im Auftrag von Joris Meys
> Gesendet: Mittwoch, 31. Januar 2018 14:02
> An: Duncan Murdoch
> Cc: r-devel
> Betreff: [EXT] Re: [Rd] Best practices in developing package: From a single 
> file
>
> On Wed, Jan 31, 2018 at 1:41 PM, Duncan Murdoch 
> wrote:
>
>> On 31/01/2018 6:33 AM, Joris Meys wrote:
>>
>> 3. given your criticism, I'd like your opinion on where I can improve
>> the
>>> documentation of https://github.com/CenterForStatistics-UGent/pim.
>>> I'm currently busy updating the help files for a next release on
>>> CRAN, so your input is more than welcome.
>>>
>>
>> After this invitation I sent some private comments to Joris.  I would
>> say his package does a pretty good job of documentation; it isn't the
>> kind of Roxygen-using package that I was complaining about.  So I will
>> say I have received an example of a Roxygen-using package that has
>> good help pages.
>>
>
> Thank you for the nice compliment and the valuable tips.
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling Ghent University 
> Coupure Links 653, B-9000 Gent (Belgium) 
> 
>
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> *
> Confidentiality Note: The information contained in this ...{{dropped:10}}
>
> __
> 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 history: Why 'L; in suffix character ‘L’ for integer constants?

[Yihui Xie]

Yeah, that was what I heard from our instructor when I was a graduate
student: L stands for Long (integer).

Regards,
Yihui
--
https://yihui.name


On Fri, Jun 16, 2017 at 11:00 AM, Serguei Sokol  wrote:
> Le 16/06/2017 à 17:54, Henrik Bengtsson a écrit :
>>
>> I'm just curious (no complaints), what was the reason for choosing the
>> letter 'L' as a suffix for integer constants?  Does it stand for
>> something (literal?), is it because it visually stands out, ..., or no
>> specific reason at all?
>
> My guess is that it is inherited form C "long integer" type (contrary to
> "short integer" or simply "integer")
> https://en.wikipedia.org/wiki/C_data_types

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

Re: [Rd] [FORGED] Re: Replaying a recorded plot (mixed base and grid) from pdf() in cairo_pdf() crashes R

[Yihui Xie]

Thanks a lot! I don't use cairo_pdf() very often. I discovered this
problem because a user reported an issue with cairo_pdf() in knitr,
and I found it was reproducible without using knitr.

Regards,
Yihui
--
https://yihui.name


On Tue, Feb 21, 2017 at 5:32 PM, Paul Murrell  wrote:
> Hi
>
> I decided to blame cairo_pdf().
>
> There is a fix in r-devel (r72242) that works for the reported case, plus
> some basic sanity checks.
>
> I could not complete 'make check-devel' because it was failing on
> reg-tests-1d.R ...
>
>> stopifnot(length(fd) == 10, identical(fd, format(dct <- as.POSIXct(dlt
> Error: identical(fd, format(dct <- as.POSIXct(dlt))) is not TRUE
>
> ... anyone else seeing that ?
>
> I would appreciate confirmation from a heavier user of cairo_pdf() that I
> have not broken anything.
>
> Paul
>
>
> On 21/02/17 08:27, Paul Murrell wrote:
>>
>> Hi
>>
>> This appears to be happening (at least) because cairo_pdf() delays
>> initialising a Cairo surface until BM_NewPage(), rather than
>> initiliasing a Cairo surface in BM_Open(), and replayPlot() triggers
>> some activity (set clip region) on the device BEFORE a new page is
>> started (so the pointer to the Cairo surface is null, so BOOM).
>>
>> Not sure yet whether to blame replayPlot() for not starting with a new
>> page operation OR to blame cairo_pdf() for not initialising a Cairo
>> surface at device startup.
>>
>> If anyone who knows more about Cairo (or cairo_pdf()) wants to point out
>> a good reason for the way cairo_pdf() currently works, please don't hold
>> back.
>>
>> Paul
>>
>> On 21/02/17 05:30, Yihui Xie wrote:
>>>
>>> A quick follow-up: I just used cairo_pdf() as the recording device,
>>> and it crashes R as well, so it is probably not relevant to pdf() but
>>> an issue specific to cairo_pdf().
>>>
>>> cairo_pdf()
>>> dev.control('enable')
>>>
>>> library("grid")
>>> plot(1)
>>> grid.text("A")
>>>
>>> res = recordPlot()
>>> dev.off()
>>>
>>> cairo_pdf()
>>> replayPlot(res)
>>> dev.off()
>>>
>>>
>>> Regards,
>>> Yihui
>>> --
>>> https://yihui.name
>>>
>>>
>>> On Mon, Feb 20, 2017 at 10:24 AM, Yihui Xie  wrote:
>>>>
>>>> Hi,
>>>>
>>>> I wonder if this is expected or I'm doing a wrong thing.
>>>>
>>>> pdf()
>>>> dev.control('enable')
>>>>
>>>> library("grid")
>>>> plot(1)
>>>> grid.text("A")
>>>>
>>>> res = recordPlot()
>>>> dev.off()
>>>>
>>>> cairo_pdf()
>>>> replayPlot(res)
>>>> dev.off()
>>>>
>>>>
>>>>  *** caught segfault ***
>>>> address 0x4, cause 'memory not mapped'
>>>>
>>>>
>>>>> sessionInfo()
>>>>
>>>> R version 3.3.2 (2016-10-31)
>>>> Platform: x86_64-apple-darwin13.4.0 (64-bit)
>>>> Running under: macOS Sierra 10.12.3
>>>>
>>>> locale:
>>>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>>>>
>>>> attached base packages:
>>>> [1] stats graphics  grDevices utils datasets  methods   base
>>>>
>>>> loaded via a namespace (and not attached):
>>>> [1] tools_3.3.2 yaml_2.1.14
>>>>
>>>> Regards,
>>>> Yihui
>>>> --
>>>> https://yihui.name
>>>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/

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

Re: [Rd] Replaying a recorded plot (mixed base and grid) from pdf() in cairo_pdf() crashes R

[Yihui Xie]

A quick follow-up: I just used cairo_pdf() as the recording device,
and it crashes R as well, so it is probably not relevant to pdf() but
an issue specific to cairo_pdf().

cairo_pdf()
dev.control('enable')

library("grid")
plot(1)
grid.text("A")

res = recordPlot()
dev.off()

cairo_pdf()
replayPlot(res)
dev.off()


Regards,
Yihui
--
https://yihui.name


On Mon, Feb 20, 2017 at 10:24 AM, Yihui Xie  wrote:
> Hi,
>
> I wonder if this is expected or I'm doing a wrong thing.
>
> pdf()
> dev.control('enable')
>
> library("grid")
> plot(1)
> grid.text("A")
>
> res = recordPlot()
> dev.off()
>
> cairo_pdf()
> replayPlot(res)
> dev.off()
>
>
>  *** caught segfault ***
> address 0x4, cause 'memory not mapped'
>
>
>> sessionInfo()
> R version 3.3.2 (2016-10-31)
> Platform: x86_64-apple-darwin13.4.0 (64-bit)
> Running under: macOS Sierra 10.12.3
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] tools_3.3.2 yaml_2.1.14
>
> Regards,
> Yihui
> --
> https://yihui.name

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

[Rd] Replaying a recorded plot (mixed base and grid) from pdf() in cairo_pdf() crashes R

[Yihui Xie]

Hi,

I wonder if this is expected or I'm doing a wrong thing.

pdf()
dev.control('enable')

library("grid")
plot(1)
grid.text("A")

res = recordPlot()
dev.off()

cairo_pdf()
replayPlot(res)
dev.off()


 *** caught segfault ***
address 0x4, cause 'memory not mapped'


> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: macOS Sierra 10.12.3

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

loaded via a namespace (and not attached):
[1] tools_3.3.2 yaml_2.1.14

Regards,
Yihui
--
https://yihui.name

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

[Rd] Suppress LaTeX log during R CMD build

[Yihui Xie]

Hi,

When a package's documentation contains \Sexpr{}, R CMD build will
build the manual to PDF. I wonder if the full LaTeX log could be
suppressed in this case. Currently it looks like this:

$ R CMD build foo

* checking for file ‘foo/DESCRIPTION’ ... OK
* preparing ‘foo’:
* checking DESCRIPTION meta-information ... OK
* installing the package to process help pages
* building the PDF package manual
Hmm ... looks like a package
Converting Rd files to LaTeX ..
Creating pdf output from LaTeX ...

This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode

(/private/var/folders/8r/zh8x49md6vsgskh23jrmy7p8gn/T/RtmpWxPLW3/Rbuild52f3
1a8c19c2/foo/.Rd2pdf21235/Rd2.tex
LaTeX2e <2016/03/31>
Babel <3.9r> and hyphenation patterns for 22 language(s) loaded.
(/usr/local/texlive/2016basic/texmf-dist/tex/latex/base/book.cls
Document Class: book 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2016basic/texmf-dist/tex/latex/base/bk10.clo))
(/Library/Frameworks/R.framework/Resources/share/texmf/tex/latex/Rd.sty


Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name

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

Re: [Rd] Warn on partial matches in R CMD check

[Yihui Xie]

+1 "What you write is **probably** what you get" sounds like a very
bad idea to me. The real solution to laziness should be
auto-completion instead of partial matching.

Regards,
Yihui


On Wed, Jan 20, 2016 at 4:13 PM, Hadley Wickham  wrote:
> Hi all (but especially Kurt),
>
> Would it be possible to have a flag to R CMD check that warned on
> partial all matches, i.e. turning on:
>
> options(
>   warnPartialMatchDollar = TRUE,
>   warnPartialMatchArgs = TRUE,
>   warnPartialMatchAttr = TRUE
> )
>
> I think this is good practice for package code.
>
> I don't think it can currently be made part of the default (because
> sometimes the warnings come from other packages), but it would be
> really convenient to have as a switch.
>
> Hadley
>
> --
> http://had.co.nz/
>
> __
> 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] MetaCran website v1.0.0-alpha

[Yihui Xie]

I cannot speak for other package authors, but for all my own packages,
I have provided the BugReports field in DESCRIPTION that points to the
Github issues page. You can probably use this field to check if a
package is on Github or not. If it is, you may just fork the original
repo instead of creating a new one from the CRAN package. I'm not sure
how technically difficult it would be for you. Thanks for the
wonderful work!

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Tue, May 26, 2015 at 2:45 AM, Gábor Csárdi  wrote:
> On Mon, May 25, 2015 at 8:28 PM, Simon Urbanek 
> wrote:
>
>> One issue I have with this is that it doesn't point to the original GitHub
>> repositories of the packages, so you end up with additional repositories on
>> Github in Gabor's name that have nothing to do with the actual Github
>> repositories of the packages. I understand that it's technically necessary,
>> but I fear it will lead to a lot of confusion...
>
>
> Well, we point to the original GitHub repo is that is given in the URL
> field. It would be nice to have an "official" field for source code
> repository in DESCRIPTION.
>
> But I agree with you that this has great potential for confusion. Several
> people have been sending pull requests to github.com/cran repos, most of
> them not realizing that they are not the right repos to fork. (Although
> many packages are not on GH or any other similar service, and then are kind
> of the places to fork.)
>
> I could have a large warning popup on the link from r-pkg.org, with red
> flags, and you would see this before the actual repo. But this has its own
> problems, like being annoying after a while, how to turn it off with
> browser cookies, etc.
>
> The best would be to somehow have a warning on the GitHub repo pages, but
> there isn't a lot I can modify there if I don't want to change/add the
> README file, which would effectively change the package. I could probably
> add 'WARNING: this is a read-only mirror, and not the original package
> repository' to the one-line description on the top.
>
> If you have other ideas, please let me know.
>
> Gabor

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

Re: [Rd] NEWS.md support on CRAN

[Yihui Xie]

That is more or less what I had been doing for a long time (having
both NEWS.md and NEWS), but decided not to do it any more last year.
In fact, you can easily convert NEWS.md to a NEWS file that R's news()
can understand, e.g.
https://github.com/yihui/knitr/blob/947ad5fc94/Makefile#L8-L10 (if
your NEWS.md is like this
https://raw.githubusercontent.com/yihui/knitr/947ad5fc94/NEWS.md)

I stopped doing this because as I said, I found Github release notes
much more pleasant to read (https://github.com/yihui/knitr/releases),
and I do not care much about the possibility that some users do not
have internet connections when reading the NEWS (it is a legitimate
concern, though). IMHO, it is totally worth it if we are talking about
official support of Markdown in R's documentation system (.Rd files),
and it is probably not worth the time and effort if we only want to
support NEWS.md in particular. That is just a tiny problem compared to
the effort of porting CommonMark or whatever Markdown rendering
engines into R.

Regards,
Yihui


On Sun, May 24, 2015 at 7:58 AM, Duncan Murdoch
 wrote:
>
> I imagine GitHub users could have both NEWS.md and NEWS, with one being
> a symlink to the other, and .Rbuildignore set to ignore NEWS.md.  Why
> not try it, and post instructions for other Github users?  news() won't
> be able to understand the headings, but it should display the file as a
> bunch of text.
>
> Duncan Murdoch

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

Re: [Rd] NEWS.md support on CRAN

[Yihui Xie]

I agree. It is not worth all the trouble just to save the "bit of
hassle to go to the package's Github site". In fact, the release notes
on Github are more meaningful than a plain text NEWS.md or even a
converted NEWS.html from Pandoc, e.g. you can include bug report
numbers and attribute to users by @username (they all have hyperlinks
attached on them, so it is easy to see more details of bugs/features
if one really cares). Personally, I feel it is very worthwhile going
to Github and reading the release notes there. I'd be unhappy with
converting NEWS.md to NEWS.html by Pandoc. I know not all people use
Github, but I feel if a package author has a NEWS.md, chances are this
package is on Github.

Re Kurt's analysis of NEWS.md on CRAN, I guess that is because R CMD
check will warn against NEWS.md at the top level. I know a lot of
packages on Github have the NEWS.md file, and it has been removed from
the tarball to make R CMD check happy.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Sat, May 23, 2015 at 8:25 AM, Gábor Csárdi  wrote:
> On Sat, May 23, 2015 at 8:14 AM, Duncan Murdoch 
> wrote:
> [...]
>
>> I think the harder problem is display.  CRAN can run pandoc, but can
>> users who install the package from source?  I would expect some obscure
>> platforms (like Windows ;-) would not have it available.
>>
> [...]
>
> I don't think pandoc is the best way to go with NEWS.md (and README.md,
> actually). I would be surprised if many package maintainer built their
> NEWS/README files with pandoc. They just look at them at GitHub (or another
> similar service).
>
> GitHub has API for building HTML from MarkDown:
> https://developer.github.com/v3/markdown/
> It can build GitHub-flavored MarkDown, in which case you get links to
> GitHub issues, etc. or just plain MarkDown, like a GitHub README.
>
> If you don't want to rely on their service, then there are a multitude of
> lightweight MarkDown parsers available, e.g.
> https://github.com/markdown-it/markdown-it is a good one IMO.
>
> Pandoc is great for vignettes, but you don't need its full power for
> READMEs and especially not for NEWS files. In fact most NEWS.md files look
> good as text.
>
> Gabor

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

Re: [Rd] NEWS.md support on CRAN

[Yihui Xie]

What I do is to use inst/NEWS.Rd as a placeholder that points to the
NEWS.md on Github, e.g.
http://cran.rstudio.com/web/packages/knitr/index.html

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Fri, May 22, 2015 at 8:08 PM, Duncan Murdoch
 wrote:
> On 22/05/2015 8:49 PM, Imanuel Costigan wrote:
>> Are there any plans for CRAN to support NEWS files in markdown? Bit of a 
>> hassle to go the the package’s Github (or other like) site to read NEWS.
>
> Not as far as I know.  There have been discussions about increasing the
> support of Markdown, but so far the conclusion has been that it's too
> hard to do -- the support is not stable enough on all the platforms
> where R runs.
>
> Markdown is allowed for vignettes (because the package author processes
> those), so I'd suggest putting your news into a vignette instead of a
> news file.  Put in a token news file that points to the vignette so
> users can find it.
>
> Duncan Murdoch

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

Re: [Rd] How best to get around shadowing of executables by system()'s prepending of directories to Windows' PATH?

[Yihui Xie]

+1 I have exactly the same problem.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Mon, May 18, 2015 at 12:29 PM, Josh O'Brien  wrote:
> My question:
>
> On Windows, R's system() command prepends several directories to those
> in the Windows Path variable.
>
> >From ?system
>
>  The search path for 'command' may be system-dependent: it will
>  include the R 'bin' directory, the working directory and the
>  Windows system directories before 'PATH'.
>
> This shadows any executables on the Path that share a name with, for
> example, one of the Windows commands.
>
> What should I do when I'd really like (the equivalent of) a call
> passed to system() that would be executed using the same Path that
> you'd get if working directly at the Windows command line? Is there a
> recommended workaround for situtations like this? (It _seems_ like it
> would be handy if system() et al. included an additional argument that
> optionally disabled the prepending of those extra directories, to give
> Windows users full control of the path seen by system(). Would adding
> such an argument have undesirable ramifications?)
>
>
> Motivation and reproducible example:
>
> I'm motivated here by a desire to use the function plotdiff() from
> Paul Murrell's gridGraphics package on my Windows laptop.  Getting
> that to work will require a few code fixes, of which the masking of
> ImageMagick's convert.exe by that in the C:/Windows/System32 seems to
> be the most challenging. plotdiff() relies on system2() calls to
> ImageMagick's 'convert'  function, as well as a call to
> Sys.which(c("convert", "compare")) that tests for the presence of
> ImageMagick on the Path. Even  if ImageMagick is placed early on the
> Path, though, both calls to Sys.which() and system2() find Windows'
> convert command  (which "Converts FAT volumes to NTFS") rather than
> ImageMagick's convert.
>
>
> Here's a reproducible example that shows what I'm seeing:
>
> ## In R, make a pdf
> pdf("a.pdf")
> plot(rnorm(99), col="red")
> dev.off()
>
> ## At Windows cmd command line
> where convert
> ## C:\Program Files\ImageMagick-6.8.8-Q16\convert.exe
> ## C:\Windows\System32\convert.exe
> convert -density 100x100 a.pdf a.png
>
> ## From R
>
> ## Unqualified references to convert find the 'wrong' one
> Sys.which("convert")
> ##   convert
> ## "C:\\Windows\\system32\\convert.exe"
>  system2("convert",  "-density 100x100 a.pdf b.png")
> ## Invalid Parameter - 100x100
> ## Warning message:
> ## running command '"convert" -density 100x100 a.pdf b.png' had status 4
>
> ## A fully qualified reference does work
> system2("C:/Program Files/ImageMagick-6.8.8-Q16/convert",
> "-density 100x100 a.pdf b.png")
>
> __
> 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] UTF8 markdown vignette

[Yihui Xie]

For the record, I saw a change had been made in R-devel:
https://github.com/wch/r-source/commit/d53b098 (Thanks, Duncan)
Meanwhile, I also made a change in knitr to assume UTF-8 unless R
passes an encoding to the vignette engine:
https://github.com/yihui/knitr/commit/23c6c8e2 Both will solve the
original problem, but apparently the former one is the ideal fix.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Wed, Dec 10, 2014 at 6:19 AM, Duncan Murdoch
 wrote:
> On 09/12/2014, 10:36 PM, Yihui Xie wrote:
>> I took a look at the R source and I realized that the encoding was
>> actually never passed to the vignette engine:
>> https://github.com/wch/r-source/blob/e721ef5f4/src/library/tools/R/Vignettes.R#L507
>> Apparently only the file and quiet arguments are passed to the
>> vignette engine. Did I miss anything?
>
> I think it's actually a little messier than that:  sometimes the
> encoding is passed (e.g. by tools:::.run_one_vignette, used in R CMD
> check), but not always.  Here's what I think should happen instead:
>
> When building a vignette in a package, R knows the encoding declared for
> the package, so it should assume this as the default for the vignette.
> If nothing is declared, it should assume "native.enc", i.e. whatever is
> the native encoding on the machine it's running on.
>
> For each vignette, at the same time as it determines the vignette
> engine, it should see whether there is a declared encoding within the
> vignette.
>
> When it calls the engine, it should pass an encoding (and it should be a
> legal one, e.g. UTF-8, not utf8).
>
> Unless I notice something missing when I do this, or someone else tells
> me something that's missing, I'll try to make the changes above in
> R-devel and R-patched sometime before 3.1.3 is released.
>
> In the meantime, unless declaring a dependence on R >= 3.1.3, vignette
> engines should determine the encoding themselves whenever they are
> called without an "encoding" argument.
>
> Duncan Murdoch

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

Re: [Rd] UTF8 markdown vignette

[Yihui Xie]

I took a look at the R source and I realized that the encoding was
actually never passed to the vignette engine:
https://github.com/wch/r-source/blob/e721ef5f4/src/library/tools/R/Vignettes.R#L507
Apparently only the file and quiet arguments are passed to the
vignette engine. Did I miss anything?

To Thierry: I explicitly asked for library(rmarkdown);sessionInfo(),
but you only told me the version of rmarkdown, which is not the only
thing I was asking for. It is extremely important in this case to know
the versions of other packages as well as your system locale
information.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Tue, Dec 9, 2014 at 3:42 PM, Duncan Murdoch  wrote:
> On 09/12/2014, 4:38 PM, ONKELINX, Thierry wrote:
>> Dear Yihui,
>>
>> I have created a reproducible example at 
>> https://github.com/ThierryO/utf8vignette
>>
>> The \usepackage{} line is needed, otherwise R CMD check --as-cran will give 
>> a warning.
>> %\VignetteEncoding{UTF-8} did not solve the problem.
>
> I've just taken a look at the sources, and that's only in R-devel, it
> never got backported to R-patched so it isn't in the release R.  You
> would need to use
>
> %\SweaveUTF8
>
> instead.  (It was introduced in 3.1.0, and should be kept until at least
> 3.2.0, but \VignetteEncoding will be preferred in the long run.  It
> should make it into 3.1.3 unless we drop the ball again.)
>
> Duncan Murdoch
>
>>
>> I use rmarkdown_0.3.11
>>
>> HTML vignette is not an option as the vignette demonstrates the use of a 
>> custom beamer output format.
>>
>> Best regards,
>>
>> Thierry
>> 
>> Van: xieyi...@gmail.com [xieyi...@gmail.com] namens Yihui Xie 
>> [x...@yihui.name]
>> Verzonden: dinsdag 9 december 2014 17:13
>> Aan: ONKELINX, Thierry
>> CC: r-devel@r-project.org; Duncan Murdoch; Kurt Hornik
>> Onderwerp: Re: [Rd] UTF8 markdown vignette
>>
>>
>> Lastly, the most important piece of information is missing in this
>> post: library(rmarkdown); sessionInfo(). There is not a minimal
>> reproducible example, either. Without these information, I can only
>> guess blindly.

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

Re: [Rd] UTF8 markdown vignette

[Yihui Xie]

Thanks for the kind words. Actually we have more ambitious plans than
just reverse search :)

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Tue, Dec 9, 2014 at 11:18 AM, Duncan Murdoch
 wrote:
> On 09/12/2014 11:13 AM, Yihui Xie wrote:
>>
>> Lastly, the most important piece of information is missing in this
>> post: library(rmarkdown); sessionInfo(). There is not a minimal
>> reproducible example, either. Without these information, I can only
>> guess blindly.
>>
>> BTW, you may also try HTML vignettes instead, which is much much
>> easier to get right than LaTeX in terms of character encodings.
>
>
> Over the last while I've been writing an HTML vignette, and I really want to
> compliment Yihui and the other rmarkdown folks for doing a fantastic job
> with them.  I haven't had to deal with encoding issues, but overall markdown
> + R + HTML is a very pleasant way to work.   I just wish someone would
> implement reverse search ... :-).
>
> Duncan Murdoch

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

Re: [Rd] UTF8 markdown vignette

[Yihui Xie]

A few things to clarify:

1. You do not necessarily have to keep the \usepackage{} line if you
use %\VignetteEncoding{UTF-8}, because Pandoc will use UTF-8 anyway in
its LaTeX template.

2. Perhaps the vignette engine in R has done something clever to
convert utf8 to UTF-8, but I'd recommend %\VignetteEncoding{UTF-8}
instead of %\VignetteEncoding{utf8} to make sure it is a valid
encoding name, e.g.

> 'utf8' %in% iconvlist()
[1] FALSE
> 'UTF-8' %in% iconvlist()
[1] TRUE
> 'UTF8' %in% iconvlist()
[1] TRUE

BTW, %\VignetteEncoding is not documented anywhere (Cc'ing Kurt), and
I think it needs to be documented, since the old approach
\usepackage[enc]{inputenc} was basically a hack, which looks really
odd in non-LaTeX vignettes (e.g. HTML vignettes).

3. The default `encoding` argument of rmarkdown::render() is not
relevant here, even if its value is native.enc. When R build a
vignette, it tries to detect its encoding and pass it to the vignette
engine, so the default argument value may not be native.enc.

Lastly, the most important piece of information is missing in this
post: library(rmarkdown); sessionInfo(). There is not a minimal
reproducible example, either. Without these information, I can only
guess blindly.

BTW, you may also try HTML vignettes instead, which is much much
easier to get right than LaTeX in terms of character encodings.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Tue, Dec 9, 2014 at 7:05 AM, Duncan Murdoch  wrote:
> On 09/12/2014, 5:19 AM, ONKELINX, Thierry wrote:
>> Dear Duncan,
>>
>> The UTF-8 characters aren't properly rendered in the pdf version of the 
>> vignette.
>> $£€ âêîûô äëïöüÿ áéíóúý àèìòù ãñ çµ is rendered as $£€ âêîûô 
>> äëïöüÿ áéà óúý à èìòù ãñçµ
>
> That looks as though the UTF-8 characters are being interpreted as
> Latin1 characters (or whatever your native encoding is on Windows) when
> read from the file.
>
> It is quite tricky to work with UTF-8 in R in Windows.  I think Sweave
> does it properly, though there may be exceptions.  The issue is that
> many character input routines assume characters start out in the native
> encoding.  (There's also a translation that happens by default on
> output, but I don't think that's your problem.)  So the way to debug
> this is to follow all of the I/O, and see where the misinterpretation
> happens.  For vignettes, things are complicated, because R reads the
> file to determine which vignette engine to use, then the vignette engine
> reads it (perhaps more than once).
>
>
>> The same problem occurs when I use render("vignette.md", output_format = 
>> "mypackage::mystyle"), instead of render("vignette.md", output_format = 
>> "mypackage::mystyle", encoding = "UTF-8"). The default value of the encoding 
>> argument of rmarkdown::render() is
> encoding = getOption("encoding"), which is "native.enc" on my system.
>>
>
> It sounds as though the render function needs a way to determine the
> encoding from the file itself.  Recent Sweave versions support the
> declaration
>
> %\VignetteEncoding{utf8}
>
> as well as the older
>
> \usepackage[utf8]{inputenc}
>
> that you used.  You might want to try that line as well.  (You need to
> keep the \usepackage line to tell LaTeX what encoding you're using.)
>
> Duncan Murdoch
>
>
>> I'll post the question on an RStudio forum as well.
>>
>> Best regards,
>>
>> Thierry
>>
>>
>> -Oorspronkelijk bericht-
>> Van: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>> Verzonden: dinsdag 9 december 2014 11:04
>> Aan: ONKELINX, Thierry; r-devel@r-project.org
>> Onderwerp: Re: [Rd] UTF8 markdown vignette
>>
>> On 09/12/2014, 4:48 AM, ONKELINX, Thierry wrote:
>>> Dear all,
>>>
>>> I'm trying to use a Markdown vignette with UTF-8 encoding. It compiles well 
>>> when knitting the vignette in RStudio, but it fails to recognize the UTF-8 
>>> settings when building the source package. Can someone point out what I'm 
>>> doing wrong? I tried to put the relevant information below.
>>
>> You don't describe the symptoms of "failing to recognize", but from the look 
>> of it, this is a problem with the knitr::rmarkdown engine or with the 
>> devtools packaging, so you should probably ask on an RStudio forum.
>>
>> Duncan Murdoch
>>
>>> Best regards,
>>>
>>> Thierry
>>>
>>> Details:
>>>
>>> Using 64-bit R 3.1.2 with encoding = "native.enc" on Windows 7 with Rstudio 
>

Re: [Rd] Use of tools:::httpdPort in a package for CRAN.

[Yihui Xie]

Perhaps I missed something, but isn't this just a one-liner function?

help.index = function (pkg) help(package = (pkg), help_type = "html")

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Fri, Dec 5, 2014 at 10:24 AM, Sven E. Templer  wrote:
> Hello,
>
> I wrote a function to show the help/index page of a package in a
> browser (and want to include this in an update for a CRAN package). I
> asked in R-help how to obtain the 00Index.html file, Duncan Murdoch
> suggested to inspect (see
> http://r.789695.n4.nabble.com/Obtain-00Index-html-tt4697661.html)
> tools:::httpd (thank you therefore!). So I came up with:
>
>
> help.index <- function (pkg, browser = NA, encodeIfNeeded = FALSE) {
>
> pkg <- as.character(substitute(pkg))
> hport <- tools:::httpdPort
>
> if (!pkg %in% rownames(installed.packages()))
> stop(paste("Package", pkg, "not found."))
>
> if (hport == 0) {
> cat("Starting dynamic help.\n")
> t <- try(startDynamicHelp(), silent = TRUE)
> if (class(t) == "try-error")
> stop("Could not start dynamic help.")
> hport <- tools:::httpdPort
> }
>
> if (!is.na(browser)) {
> if (tolower(browser) == "rstudio")
> options(browser = function (x) .Call("rs_browseURL", url))
> else
> options(browser = browser)
> }
>
> url <- paste0("http://127.0.0.1:";, hport, "/library/", pkg,
> "/html/00Index.html")
> browseURL(url, encodeIfNeeded = encodeIfNeeded)
> invisible(NULL)
>
> }
>
> (also at https://github.com/setempler/miscset/blob/master/R/help.index.R)
>
> I tried to avoid `:::` so I used the 00Index.html file from the
> library on my disk (like
> /home/user.foo/R/lib.bar/package.baz/html/00Index.html). It does show
> the index, but the link to the help pages are not accessible.
> Nevertheless, my implementation now works, but R CMD check --as-cran
> gives a warning, and the R help also says to avoid `:::`. Also
> get(httpd, as.environment("package:tools")) didn't help.
>
> My question: do I have another possibility to achieve my goal without
> referencing by `:::` (concerning a submission to CRAN), if so, please
> tell me!
>
> Thank you in advance,
> Sven.
>
> __
> 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] Changing style for the Sweave vignettes

[Yihui Xie]

As someone who was also annoyed by command line prompts a couple of
years ago, I wrote knitr and removed prompts as well as the
continuation characters (+) by default (FAQ5:
https://github.com/yihui/knitr/blob/master/FAQ.md).

BTW, I do not always trust copying text from PDF. Perhaps it is fine
for code/text in verbatim environments (as Paul indicated above).
LaTeX users are probably aware of ligatures (e.g. for "ff") and the
fact that leading/trailing white spaces are often removed in the PDF
output, which will make "What You Copy is Not What You Get".
Personally I think HTML is more reliable in this respect (
is more faithful), and this is one of the reasons that I'm in favor of
HTML vignettes instead of PDF when I do not care that much about
precise typesetting (which is not always the most important thing).

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Thu, Nov 13, 2014 at 10:10 AM, January Weiner
 wrote:
> Dear Paul and Martin,
>
> thanks for the useful tips. I'll start with Paul's suggestion (getting
> rid of these '+'-es will already be a boon!), and move from my old
> Sweave vignettes when possible.
>
> Thank you!
> j.
>
> On 13 November 2014 15:35, Paul Gilbert  wrote:
>> You might also consider starting your vignettes with
>>
>> \begin{Scode}{echo=FALSE,results=hide}
>>  options(continue="  ")
>> \end{Scode}
>>
>> Then you get one prompt but it is still easy to cut and paste. This has been
>> in many of my packages for many years, so I think it would be fair to assume
>> it is acceptable.
>>
>> Paul
>>
>>
>> On 11/13/2014 06:56 AM, January Weiner wrote:
>>>
>>> Thank you, Søren and Brian for your answers.
>>>
>>> Whether this is the right list -- well, I think it is, since I am
>>> developing a package and would like to create a vignette which is
>>> useful and convenient for my users. I know how to extract the vignette
>>> code. However, most of my users don't.  Or if they do, they do not
>>> bother, but copy the examples from the PDF while they are reading it.
>>> At least that is my observation.
>>>
>>> I'm sorry that my e-mail was unclear -- I started my e-mail with "as a
>>> user, ...", but I did mention that it is my vignettes that I am
>>> concerned with.
>>>
>>> options(prompt=...) is an idea, though I'm still not sure as to the
>>> second part of my question - whether a vignette without a command
>>> prompt is acceptable in a package or not.
>>>
>>> Kind regards,
>>>
>>> j.
>>>
>>>
>>> On 13 November 2014 12:36, Brian G. Peterson  wrote:
>>>>
>>>> On 11/13/2014 05:09 AM, January Weiner wrote:
>>>>>
>>>>>
>>>>> As a user, I am always annoyed beyond measure that Sweave vignettes
>>>>> precede the code by a command line prompt. It makes running examples
>>>>> by simple copying of the commands from the vignette to the console a
>>>>> pain. I know the idea is that it is clear what is the command, and
>>>>> what is the output, but I'd rather precede the output with some kind
>>>>> of marking.
>>>>>
>>>>> Is there any other solution possible / allowed in vignettes? I would
>>>>> much prefer to make my vignettes easier to use for people like me.
>>>>
>>>>
>>>>
>>>> I agree with Søren that this is not the right list, but to complete the
>>>> thread...
>>>>
>>>> See the examples in
>>>>
>>>> ?vignette
>>>>
>>>> start just above
>>>>
>>>> ## Now let us have a closer look at the code
>>>>
>>>> All vignette's are compiled.  You can trivially extract all the code used
>>>> for any vignette in R, including any code not displayed in the text and
>>>> hidden from the user, from within R, or saved out to an editor so you can
>>>> source it line by line from Rstudio (or vim or emacs or...). That's the
>>>> whole point.
>>>>
>>>> Regards,
>>>>
>>>> Brian
>>>>
>>>> --
>>>> Brian G. Peterson
>>>> http://braverock.com/brian/
>>>> Ph: 773-459-4973
>>>> IM: bgpbraverock

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

Re: [Rd] Pkg creation: Sweave: multiple files vignette: Error in R CMD check

[Yihui Xie]

My guess is that your child Rnw file was not copied to inst/doc during
R CMD build or check. You may read the section 1.4 of the R-exts
manual: 
http://cran.rstudio.com/doc/manuals/r-release/R-exts.html#Writing-package-vignettes

> When R CMD build builds the vignettes, it copies these and the vignette 
> sources from directory vignettes to inst/doc. To install any other files from 
> the vignettes directory, include a file vignettes/.install_extras which 
> specifies these as Perl-like regular expressions on one or more lines. (See 
> the description of the .Rinstignore file for full details.)

So it seems you will need a .install_extras file to make sure the
child Rnw file is copied along with the parent .Rnw. I do not think
you have to obfuscate the path of the child Rnw file like
../../whatever/... but you do have to change its file extension if and
only if you put it under the root directory vignettes/ (it should be
fine if it is under a sub directory).

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Thu, Nov 6, 2014 at 8:44 AM,   wrote:
> Hello R-developers!
>
> First I want to thank Duncan, Sean and Ben (off-list-communication) for your
> comments and suggestions!
>
>
> Unfortunetly the renaming of the child.Rnw file to e.g. child.sub and also the
> usage of an other file type like child.txt did not solve the Problem.
> I got an ERROR in the beginning of the check process:
> ###
> ...
> ** installing vignettes
>‘Master.Rnw’ using ‘UTF-8’
> Error in SweaveReadFile(c(ifile, file), syntax, encoding = encoding) :
>   no Sweave file with name ‘./TitlePage.sub’ found
> ERROR: installing vignettes failed
> * removing ‘/tmp/Rtmp1iHmcw/Rinst1bc110488fde/trajaggr’
>   ---
> ERROR: package installation failed
> ###
>
>
> I found a workaround which passes the "installing vignettes" process. In this
> workaround the child.Rnw file (here: TitlePage.Rnw) is placed in a subfolder
> of the  vignettes folder and \SweaveInput{} in the Master.Rnw-file looks like
> this:
> ...
> \SweaveInput{../../../../../../../../home/harry/.../R/R_wd/myPkg/.../vignettes/TitlePage/TitlePage.Rnw}
> ..
>
> (By the way I do not see the difference between this and the original approach
> with \SweaveInput{TitlePage/TitlePage.Rnw})
>
> Unfortunetly there is still an issue related to this workaround!
> I got a NOTE related to "checking re-building of vignette outputs" in the end
> of the check process:
> ###
> * checking running R code from vignettes ...
>‘Master.Rnw’ using ‘UTF-8’ ... OK
>  OK
> * checking re-building of vignette outputs ... NOTE
> Error in re-building vignettes:
>   ...
> Fehler: Verarbeitung der Vignette 'Master.Rnw' mit folgender Diagnose
> fehlgeschlagen:
> no Sweave file with name
> ‘./../../../../../../../../../home/harry/.../R/R_wd/myPkg/.../vignettes/TitlePage/TitlePage.Rnw’
> found
> ###
>
> [This workaround idea came from:
> http://r.789695.n4.nabble.com/Sweave-absolute-path-versus-relative-path-td3950135.html]
>
>
> I am a newbie related to package creation and I am confused why the Sweave
> file now is found in the beginning (original problem) but not in the end (new
> NOTE in R CMD check)?
> It seems to be a path problem. Is the "checking re-building of vignette
> outputs" done out of another origin/ folder, e.g. like out of a temporal
> created package source and / or out of /inst/doc? If it is like that this NOTE
> seems to be unsolvable!?!
> Any suggestions what to do to solve this?
>
> Thank you very much again!
> Cheers!
> Roland
>
>
>
> Duncan Murdoch schrieb am 2014-11-04:
>> On 03/11/2014, 4:08 PM, rola...@uni-muenster.de wrote:
>> > Hello R-developers!
>
>> > I am creating a package (using devtools and RStudio) and I would
>> > like to split
>> > my vignette into multiple Rnw-files.
>
>> > As an example I tried the code from:
>> > https://support.rstudio.com/hc/en-us/articles/200486298
>> > (--> Working with multiple Rnw files)
>
>> > The Rnw-files work fine with "Complie pdf" in RStudio as well as
>> > with
>> > Sweave("Master.Rnw").
>
>> > But, if I try to check my package I get the following error:
>
>> > ...
>> > * creating vignettes ... ERROR
>> > Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet =
>> > quiet,  :
>> >   Ausführen von 'texi2dvi' für 'ChapterY.tex' fehlgeschlagen.
>> > LaTeX errors:
>> > ! LaTeX Error: Missing \begin{document}.
>
>> > See the LaTeX manual or LaTeX Companion for explanation.
>> > Type  H   for im

Re: [Rd] formatR 1.0 caused error

[Yihui Xie]

Sorry, but this is a wrong list to write to. I'll reply anyway this time...

The formatR package should be irrelevant in this case -- you were
seeing warnings of deprecation. The error came from elsewhere. It is
hard to say what the problem was without a reproducible example.
Anyway, to "fix" the warnings, you can install the development version
of knitr (which I plan to release to CRAN relatively soon):

  install.packages('knitr', repos = c('http://rforge.net',
'http://cran.rstudio.com'), type = 'source')

You posted your sessionInfo() but it seems you deleted an important
part: the versions of packages, which makes it even more difficult for
others to tell what the problem could possibly be.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Thu, Sep 18, 2014 at 1:07 PM, Zhang,Jun  wrote:
> Recently in our R 3.1.0 installation the package formatR was upgraded to 
> version 1.0, doing my usual thing, I got the following error, and the 
> destination html file was not generated.
> What can I do if I want to stay at the current formatR version?
>
> Jun
>
> Error: unrecognized fields specified in html_dependency: attachment
> In addition: Warning messages:
> 1: 'function (...)
> {
> .Deprecated("tidy_source", package = "formatR")
> tidy_source(...)
> }' is deprecated.
> Use 'tidy_source' instead.
> See help("Deprecated") and help("formatR-deprecated").
> 2: In tidy_source(...) :
>   The option 'keep.blank.line' is deprecated; please use 'formatR.blank'
> 3: 'function (...)
> {
> .Deprecated("tidy_source", package = "formatR")
> tidy_source(...)
> }' is deprecated.
> Use 'tidy_source' instead.
> See help("Deprecated") and help("formatR-deprecated").
> 4: In tidy_source(...) :
>   The option 'keep.blank.line' is deprecated; please use 'formatR.blank'
> 5: 'function (...)
> {
> .Deprecated("tidy_source", package = "formatR")
> tidy_source(...)
> }' is deprecated.
> Use 'tidy_source' instead.
> See help("Deprecated") and help("formatR-deprecated").
> 6: In tidy_source(...) :
>   The option 'keep.blank.line' is deprecated; please use 'formatR.blank'
>> sessionInfo()
> R version 3.1.0 (2014-04-10)
> Platform: x86_64-unknown-linux-gnu (64-bit)

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

Re: [Rd] r wiki

[Yihui Xie]

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] timings for examples in R CMD check

[Yihui Xie]

I did not really try it, but perhaps setting _R_CHECK_TIMINGS_=false
in your ~/.Renviron works?
http://cran.rstudio.com/doc/manuals/r-release/R-ints.html#Tools

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Wed, Sep 3, 2014 at 2:58 PM, Brian G. Peterson  wrote:
> I'm having a very hard time making R CMD check produce a clean check on
> examples because of the timings inserted into examples by R CMD check.
>
> I am getting a difference on every example output caused by timing
> information being inserted by 'R CMD check'.
>
> The current 'Writing R Extensions' manual[1] states on p. 14:
>
>If directory tests has a subdirectory Examples containing a
>file pkg-Ex.Rout.save, this is  compared to the output file
>for running the examples when the latter are checked.
>Reference  output should be produced without having the
>--timings option set (and note that --as-cran  sets it).
>
> As is suggested above, if I run
>
>R CMD check --as-cran mypkg.tar.gz
>
> or
>
>R CMD check --timings mypkg.tar.gz
>
> the my.pkg.Rcheck/mypkg-Ex.Rout file contains timing lines inserted by 'R
> CMD check'
>
> If, instead, I follow my reading of the manual, and run
>
> R CMD check mypkg.tar.gz
>
> the mypkg.Rcheck/mypkg-Ex.Rout file does not contain timings.  If I then
> copy the mypkg.Rcheck/mypkg-Ex.Rout file to
>
> mypkg/tests/Examples/mypkg-Ex.Rout.save
>
> as described by footnote 17 on the previously referenced p. 14, I would
> expect to now have no differences, as demonstrated by 'diff' or 'diff -bw'
> as used by 'R CMD check'.
>
> To my surprise, whether I copy a version of the mypkg-Ex.Rout file with or
> without timing rows, I get differences reported for every example by the
> (spurious?) insertion of timings by R CMD check.
>
> e.g.
> 8169a8549,8550
>> > base::assign(".dptime", (proc.time() - get(".ptime", pos =
>> > "CheckExEnv")), pos = "CheckExEnv")
>> > base::cat("textplot", base::get(".format_ptime", pos =
>> > 'CheckExEnv')(get(".dptime", pos = "CheckExEnv")), "\n",
>> > file=base::get(".ExTimings", pos = 'CheckExEnv'), append=TRUE, sep="\t")
> 8175a8557
>
>
>
> Is this expected?
>
> It is certainly not the behavior we had for many years, where a check of
> examples could actually be clean, producing differences only on the 'Time
> elapsed:' line, which has been present for many R versions.  I have tried
> testing against a package with both the timing lines includes and excluded
> in /mypkg-Ex.Rout.save, and with R CMD check run without additional options,
> with --timings, and with --as-cran.   They produce equivalent check files.
> on their example checks.
>
> This behavior is on R 3.1.0, 3.1.1, and R-devel.
>
> I would assume from the documentation that there should be a way to get a
> clean check, without the timing diffs.
>
> Advice appreciated,
>
> Brian
>
> Ref:
> [1] http://cran.r-project.org/doc/manuals/R-exts.pdf
>
> --
> Brian G. Peterson
> http://braverock.com/brian/
> Ph: 773-459-4973
> IM: bgpbraverock
>
> __
> 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] Why R-project source code is not on Github

[Yihui Xie]

As someone who has merged more than a hundred pull requests on Github,
I cannot agree more. Sometimes I can take patches on my mobile phone
while I'm still in bed if they look reasonable and simple enough.
Sometimes the patches are not worth emails back and forth, such as the
correction of typos. I cannot think of anything else that is more
efficient than being able to discuss the patch right in the lines of
diff's.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Thu, Aug 21, 2014 at 10:58 AM, Simon Urbanek
 wrote:
>
> On Aug 21, 2014, at 6:40 AM, Marc Schwartz  wrote:
>
>> On Aug 21, 2014, at 3:11 AM, Gaurav Sehrawat  
>> wrote:
>>
>>> R-Project is missing something important in regards to its development ,
>>> one simply can't ignore Github ,where collaboration is at it's best .
>>>
>>> OR If i am wrong is this the correct R-source :
>>> https://github.com/wch/r-source
>>>
>>> Is anyone thinking to bring R-project org on Github ? Maybe there might be
>>> some difficulty while porting its version system to Github .
>>>
>>> Just a suggestion .
>>>
>>> Thanks
>>> Gaurav Sehrawat
>>> http://igauravsehrawat.com
>>
>>
>> The link you have above is to a read-only mirror (perhaps not the only one) 
>> of the R source code that is kept in the official Subversion repo:
>>
>>  https://svn.r-project.org/R/
>>
>> There are also some documents that describe R's development cycle and 
>> related processes:
>>
>>  http://www.r-project.org/certification.html
>>
>> Your suggestion to move to Github is perhaps based upon a false premise, 
>> that the R community at large has the ability to directly post code/patches 
>> to the official distribution. We can contribute code and patches, primarily 
>> here on R-Devel, to the code base. However, only the members of R Core team 
>> (http://www.r-project.org/contributors.html) have write access to the SVN 
>> repo above and have to approve any such contributions.
>>
>
> How is this different from Github? Github just makes it much easier to create 
> and post patches to the project - it has nothing to do with write access - 
> typically on Github the community has no write access, either. Using pull 
> requests is certainly much less fragile than e-mails and patches are based on 
> forked branches, so you can directly build the patched version if you want 
> without manually applying the patch - and you see the whole history so you 
> can pick out things logically. You can comment on individual patches to 
> discuss them and even individual commits - often leading to a quick round 
> trip time of revising it.
>
> Cheers,
> Simon

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

Re: [Rd] Parsing and deparsing of escaped unicode characters

[Yihui Xie]

The behavior depends on the specific locale. When these characters are
deparsed in a Chinese locale, they work fine, but in an English
locale, they will get escaped:

> x <- "I like \u5BFF\u53F8"
> x
[1] "I like 寿司"
> deparse(x)
[1] "\"I like 寿司\""
> sessionInfo()
R version 3.1.1 (2014-07-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=Chinese (Simplified)_People's Republic of China.936
[2] LC_CTYPE=Chinese (Simplified)_People's Republic of China.936
[3] LC_MONETARY=Chinese (Simplified)_People's Republic of China.936
[4] LC_NUMERIC=C
[5] LC_TIME=Chinese (Simplified)_People's Republic of China.936

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

> Sys.setlocale(,'English')
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> x
[1] "I like 寿司"
> deparse(x)
[1] "\"I like \""

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Mon, Jul 28, 2014 at 4:47 AM, Jeroen Ooms  wrote:
> In both R and JSON (and many other languages), unicode characters can
> be escaped using a backslash followed by a lowercase "u" and a 4 digit
> hex code. However when deparsing a character vector in R on Windows,
> the non-latin characters get escaped as " digit hex code and ">":
>
>> x <- "I like \u5BFF\u53F8"
>> cat(x)
> I like 寿司
>> src <- deparse(x)
>> cat(src)
> "I like "
>
> Same thing happens on linux when we disable UTF8:
>
> Sys.setlocale("LC_ALL", "C")
> x <- "I like \u5BFF\u53F8"
> nchar(x) #9, seems OK
> cat(deparse(x))
> "I like "
>
> As a result, the code does not parse() back into the proper unicode
> characters. I am currently using a regular expression to convert the
> output of deparse into something that parse() (and json) supports:
>
> utf8conv <- function(x) {
>   gsub("","u\\1",x)
> }
>
>> src <- utf8conv(src)
>> y <- parse(text=src)[[1]]
>> identical(x, y)
> [1] TRUE
>
> However this is suboptimal because it introduces a big performance
> overhead for large text. Several things are unclear to me:
>
>  - Why does deparse() use a different escape notation than parse? Is
> there a way to make deparse output \u for unicode instead?
>  - Why does deparse on windows escape this in the first place, and not
> keep the actual character when the locale supports it?
>
>  > sessionInfo()
> R version 3.1.1 (2014-07-10)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> __
> 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

[Rd] Byte Order Mark in ?connections

[Yihui Xie]

Hi,

There seems to be a couple of typos in the documentation of
connections about the Byte Order Mark, e.g. 0xFFFE should be 0xFEFF,
and c(0xef, 0xbb, 0xff) should be c(0xef, 0xbb, 0xbf).
https://github.com/wch/r-source/blob/4c15a67b/src/library/base/man/connections.Rd#L366-L383

> charToRaw('\UFEFF')
[1] ef bb bf

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name

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

Re: [Rd] R CMD check warning with S3 method

[Yihui Xie]

Hi Duncan,

Again, thanks a lot for making this change (help requests are tried
over all loaded instead of attached packages):
https://github.com/wch/r-source/commit/21d2f7430b4 This makes what I
proposed last time possible now: if pkg B imports FUN from A and
re-exports it, ?FUN will work after B is attached because A will also
be at least attached.

Then it will be perfect if `R CMD check` can stop warning against the
missing documentation, which is not really missing.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Fri, Jun 20, 2014 at 1:34 AM, Yihui Xie  wrote:
> but note that you will have to document it even if it is a function
> imported from another package... Perhaps help() should be intelligent
> enough to link the documentation of `FUN` from package A for package B
> when B imports `FUN` from A, and exports it in B's NAMESPACE. The
> package name of A may be obtained from
> environmentName(environment(FUN)). At the moment, since R CMD check
> will warn against the missing documentation of `FUN` in B, I have to
> copy FUN.Rd from A to B in this case, which seems to be inefficient
> and not a best way to maintain. Did I miss anything in the R-exts
> manual?
>
> Regards,
> Yihui
> --
> Yihui Xie 
> Web: http://yihui.name
>
>
> On Fri, Jun 20, 2014 at 12:19 AM, Winston Chang  
> wrote:
>> On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer  wrote:
>>
>>>  Export filter in the NAMESPACE file *without copying it* in the R source
>>> code.
>>>
>>>
>> Ah, it works! Thank you!
>>

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

Re: [Rd] user defined macros in Rd files

[Yihui Xie]

Hi Duncan,

Thanks a lot for eventually implementing this and making the Rd world
greener! https://github.com/wch/r-source/commit/ff3ea81ae87

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Wed, Oct 9, 2013 at 3:55 PM, Duncan Murdoch  wrote:
> On 13-10-09 4:34 PM, Yihui Xie wrote:
>>
>> +1. As an example, there are 91 instances of \newcommand{\CRANpkg} in
>> R source, and this number is still growing as I see:
>>
>> $ grep "newcommand{CRANpkg}" -r . | wc
>>   91  91   10317
>>
>
> So you're saying if I ever get around to doing this, I'll have to track down
> 91+ files to make use of it?  This sounds like an argument why someone else
> should do it. ;-)
>
> Duncan Murdoch
>

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

Re: [Rd] R CMD check warning with S3 method

[Yihui Xie]

but note that you will have to document it even if it is a function
imported from another package... Perhaps help() should be intelligent
enough to link the documentation of `FUN` from package A for package B
when B imports `FUN` from A, and exports it in B's NAMESPACE. The
package name of A may be obtained from
environmentName(environment(FUN)). At the moment, since R CMD check
will warn against the missing documentation of `FUN` in B, I have to
copy FUN.Rd from A to B in this case, which seems to be inefficient
and not a best way to maintain. Did I miss anything in the R-exts
manual?

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Fri, Jun 20, 2014 at 12:19 AM, Winston Chang  wrote:
> On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer  wrote:
>
>>  Export filter in the NAMESPACE file *without copying it* in the R source
>> code.
>>
>>
> Ah, it works! Thank you!
>

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

Re: [Rd] Package keyval Error: noupquote undefined

[Yihui Xie]

Cc'ing to the author of this commit.

If TeXLive >= 2013 or a certain version of inconsolata/zi4 is
required, I think it should be documented somewhere, otherwise please
consider backward compatibility with TeXLive <= 2012. Personally I
prefer the latter, given how infrequently TeXLive is upgraded. It is
not unusual to see TeXLive that has been a few years older than its
latest version.

One possible solution is to test the version of inconsolata or zi4:

\@ifpackagelater{inconsolata}{2013/06/09}{
% use noupquote
}
{
% do not use
}

although I do not quite understand the rationale to write a homemade
version of upquote in Rd.sty...

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Wed, Jun 4, 2014 at 1:18 PM, Yihui Xie  wrote:
> Hi,
>
> Due to a change in Rd.sty a few days ago
> (https://github.com/wch/r-source/commit/620eb9a#diff-3bf3d821c6faae50cd6ec931f6f63296L272),
> the default installation of TeXLive 2009 or 2012 no longer works when
> building Rd to PDF. The error log is like this:
>
> ===
> Converting Rd files to LaTeX .
> Creating pdf output from LaTeX ...
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
>   Running 'texi2dvi' on 'Rd2.tex' failed.
> LaTeX errors:
> ! Package keyval Error: noupquote undefined.
>
> See the keyval package documentation for explanation.
> Type  H   for immediate help.
>  ...
> ! Emergency stop.
>  ...
>
> l.37 \ProcessOptions*
>
> !  ==> Fatal error occurred, no output PDF file produced!
> Output:
> This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
> entering extended mode
> LaTeX2e <2009/09/24>
> Babel  and hyphenation patterns for english, usenglishmax, dumylang, 
> noh
> yphenation, loaded.
> (./Rd2.tex (/usr/share/texmf-texlive/tex/latex/base/book.cls
> Document Class: book 2007/10/19 v1.4h Standard LaTeX document class
> (/usr/share/texmf-texlive/tex/latex/base/bk10.clo))
> (/home/yihui/repos/r-source/share/texmf/tex/latex/Rd.sty
> (/usr/share/texmf-texlive/tex/latex/base/ifthen.sty)
> (/usr/share/texmf-texlive/tex/latex/tools/longtable.sty)
> (/usr/share/texmf-texlive/tex/latex/tools/bm.sty)
> (/usr/share/texmf-texlive/tex/latex/base/alltt.sty)
> (/usr/share/texmf-texlive/tex/latex/tools/verbatim.sty)
> (/usr/share/texmf-texlive/tex/latex/ltxmisc/url.sty)
> (/usr/share/texmf-texlive/tex/latex/base/textcomp.sty
> (/usr/share/texmf-texlive/tex/latex/base/ts1enc.def))
> (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
> (/usr/share/texmf-texlive/tex/latex/base/t1enc.def))
> (/usr/share/texmf-texlive/tex/latex/psnfss/times.sty)
> (/usr/share/texmf-texlive/tex/latex/inconsolata/inconsolata.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)
>
> ! Package keyval Error: noupquote undefined.
>
> See the keyval package documentation for explanation.
> Type  H   for immediate help.
>  ...
>
> l.37 \ProcessOptions*
>
> ?
> ! Emergency stop.
>  ...
>
> l.37 \ProcessOptions*
>
> !  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on Rd2.log.
> Error in running tools::texi2pdf()
> ===
>
> Here is my sessionInfo():
>
>> sessionInfo()
> R Under development (unstable) (2014-06-04 r65854)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> $ pdflatex --version
> pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian)
> kpathsea version 5.0.0
> Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
>
> The problem is reproducible with TeXLive 2012 and Ubuntu 12.04. I went
> through the R-admin manual, and I did not seem to find a requirement
> of the TeXLive version there.
>
> Here is a minimal foo.Rd that shows the problem when running `Rd CMD
> Rd2pdf foo.Rd`:
>
> \name{foo}
> \alias{foo}
> \title{Foo}
> \description{
> Bar.
> }
>
> Regards,
> Yihui
> --
> Yihui Xie 
> Web: http://yihui.name

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

[Rd] Package keyval Error: noupquote undefined

[Yihui Xie]

Hi,

Due to a change in Rd.sty a few days ago
(https://github.com/wch/r-source/commit/620eb9a#diff-3bf3d821c6faae50cd6ec931f6f63296L272),
the default installation of TeXLive 2009 or 2012 no longer works when
building Rd to PDF. The error log is like this:

===
Converting Rd files to LaTeX .
Creating pdf output from LaTeX ...
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
  Running 'texi2dvi' on 'Rd2.tex' failed.
LaTeX errors:
! Package keyval Error: noupquote undefined.

See the keyval package documentation for explanation.
Type  H   for immediate help.
 ...
! Emergency stop.
 ...

l.37 \ProcessOptions*

!  ==> Fatal error occurred, no output PDF file produced!
Output:
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
entering extended mode
LaTeX2e <2009/09/24>
Babel  and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, loaded.
(./Rd2.tex (/usr/share/texmf-texlive/tex/latex/base/book.cls
Document Class: book 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/bk10.clo))
(/home/yihui/repos/r-source/share/texmf/tex/latex/Rd.sty
(/usr/share/texmf-texlive/tex/latex/base/ifthen.sty)
(/usr/share/texmf-texlive/tex/latex/tools/longtable.sty)
(/usr/share/texmf-texlive/tex/latex/tools/bm.sty)
(/usr/share/texmf-texlive/tex/latex/base/alltt.sty)
(/usr/share/texmf-texlive/tex/latex/tools/verbatim.sty)
(/usr/share/texmf-texlive/tex/latex/ltxmisc/url.sty)
(/usr/share/texmf-texlive/tex/latex/base/textcomp.sty
(/usr/share/texmf-texlive/tex/latex/base/ts1enc.def))
(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
(/usr/share/texmf-texlive/tex/latex/base/t1enc.def))
(/usr/share/texmf-texlive/tex/latex/psnfss/times.sty)
(/usr/share/texmf-texlive/tex/latex/inconsolata/inconsolata.sty
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)

! Package keyval Error: noupquote undefined.

See the keyval package documentation for explanation.
Type  H   for immediate help.
 ...

l.37 \ProcessOptions*

?
! Emergency stop.
 ...

l.37 \ProcessOptions*

!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on Rd2.log.
Error in running tools::texi2pdf()
===

Here is my sessionInfo():

> sessionInfo()
R Under development (unstable) (2014-06-04 r65854)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

$ pdflatex --version
pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian)
kpathsea version 5.0.0
Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).

The problem is reproducible with TeXLive 2012 and Ubuntu 12.04. I went
through the R-admin manual, and I did not seem to find a requirement
of the TeXLive version there.

Here is a minimal foo.Rd that shows the problem when running `Rd CMD
Rd2pdf foo.Rd`:

\name{foo}
\alias{foo}
\title{Foo}
\description{
Bar.
}

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

As I pointed out, \Sexpr{} is not the only potential problem. Besides,
side effects are not necessarily evil in all cases.

Since I have been described as "nitpicky", it is time for me to quit
the discussion now (adjectives on personal pronouns instead of nouns
in a discussion is a sign for me to quit in my eyes). I'm fine with
optional tangling, and I believe one should not expect to reproduce
results generated by weave using a different approach, namely
tangle+source. Some people believe tangling should mandatory, and
tangle must completely match weave in terms of code evaluation. I'm
fine with that, too. I'll be happy to see improvement in tangle
functions, as well as education on good/bad side effects. I have no
intention to win the Nobel Peace Prize, so I'm not going to make
everyone agree with each other. You hold your opinions, and I hold
mine. Once again, thanks everyone for your perspectives!

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Mon, Jun 2, 2014 at 9:18 PM, Kevin Coombes  wrote:
> "Doc, it hurts when I do this."
> "So, don't do that."
>
> If no one in R Core does anything about this issue (in terms of changing
> Sweave or Stangle), then the solution still remains very simple.  Authors of
> vignettes should avoid using anything in \Sexpr{} that has a side effect. As
> long as they do that, the code will tangle correctly and produce the same
> result as Sweave.
>
> R CMD check already detects other things which may or may not be outright
> errors but are viewed as bad practice. I think it is bad practice to put
> code with side effects into an Sexpr. So, I don't do that. If I did do that
> accidentally, I really wouldn't mind if R CMD check warned me abut it.
>
>   -- Kevin

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

Well, there is still misunderstanding: there is nothing that really
stops you from tangling the vignettes, and I do not disagree that
tangle can be useful in certain cases. I'm talking about whether
package authors _must_ tangle all their vignettes, or leave some to
users to run Stangle() or knitr::purl() on the vignettes if they
really want the potentially broken R script. The prerequisite of this
question is that the current tangle functions ignore inline
expressions, and it is not totally clear whether this is good or bad.

The harm that you mentioned was not from disabling tangle, but from
the tangle function, or if you insist the current tangle function
should be what we expect, then the harm came from the improper use of
inline expressions.

I do not think it is trivial to improve the tangle function so that it
can generate an R script that fully reproduce what was done in weave.
Inline expressions are not the only thing that need improvement. If
you argue for reproducible research, I can open the Pandora's box to
make tangle even less desirable and further away from reproducible
research. For example, how about reproducing graphics using the
tangled R script? (How do you make tangle use the same graphical
device(s) as weave? How do you pass the chunk options
width/height/fig/prefix.string to tangle?) How about chunk hook
functions in getOption('SweaveHooks')? (What if they have significant
side effects such as clearing up the workspace as documented in
help(RweaveLatex)? How to reproduce these side effects in the tangled
R script?) These open-ended questions apply to both Sweave and knitr.
As the author of knitr, I feel it is very difficult to answer them.
Instead of patching tangle functions with uncertainty, personally I'd
like to stay primarily in the weave world (I admit I'm lazy and lack
confidence).

I work like Kevin Coombes in the sense that the number of times I
invoke weave is orders of magnitude greater than tangle. If you
produced a report using weave, I do not think you should expect other
people to reproduce the computation using the tangled code.

My conclusion: Is tangle useful? Yes. Must we tangle package
vignettes? Perhaps no.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Mon, Jun 2, 2014 at 12:44 PM, Duncan Murdoch
 wrote:
> On 03/06/2014, 12:58 AM, Yihui Xie wrote:
>>
>> Yes, I completely agree the tangle code should run without errors, if
>> the package author has provided such a script. However, I think it is
>> also the package author's right to choose not to provide such a
>> script, for reasons that I stated in the beginning (1. redundancy; 2.
>> tangle functions ignore inline expressions that should not be
>> ignored).
>>
>> It seems that I still need to clarify it: I'm not talking about
>> disabling _running_ the tangled code, but disabling _generating_ the
>> code _optionally_. Unless someone is arguing that the tangled code
>> _must_ be generated from vignettes, I do not think anybody in this
>> discussion really has a conflict with anybody else.
>
>
> I think that it's not a vignette if you can't tangle it.  Including \Sexpr
> expressions in the tangled code is the sort of option I would support much
> more than suppressing the ability to tangle.  (I don't think \Sexpr
> expressions should be included by default, but there's enough flexibility in
> the system that it shouldn't be hard to include them optionally.)
>
>
>>
>> Please also note that I do not expect R core or CRAN maintainers to do
>> any extra work: package authors can easily disable tangle by
>> themselves without anything special flags to R CMD build or R CMD
>> check. The vignettes are still built normally (in terms of "weave"). I
>> brought forward the discussion to hear the possible harm that I was
>> potentially not aware of when we disable tangle for R package
>> vignettes (e.g. does it affect the quality of the package?). So far I
>> have not heard real harm (I admit my judgment is subjective).
>
>
> Several of us have told you the real harm:  it means that users can't easily
> extract a script that replicates the computations done in the vignette.
> That's a useful thing to be able to do.
>
> Duncan Murdoch

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

Re: [Rd] R CMD check for the R code from vignettes -- thread fraying?

[Yihui Xie]

I asked the same question privately yesterday since I did not receive
it or find it in the archive, and it turned out he sent an off-line
reply. I'm replying publicly just to avoid further confusion, and
sorry to spam all in the list.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Mon, Jun 2, 2014 at 7:06 AM, Prof J C Nash (U30A)  wrote:
> I noted Duncan's comment that an answer had been provided, and went to
> the archives to find his earlier comment, which I am fairly sure I saw a
> day or two ago. However, neither May nor June archives show Duncan in
> the thread except for the msg below (edited for space). Possibly tech
> failures are causing misunderstandings.
>
> JN
>
> On 14-06-02 06:00 AM, r-devel-requ...@r-project.org wrote:
>> Message: 4 Date: Mon, 02 Jun 2014 14:06:28 +0900 From: Duncan Murdoch
>>  To: Carl Boettiger ,
>> Gabriel Becker  Cc: Henrik Bengtsson
>> , R-devel  Subject: Re: [Rd]
>> R CMD check for the R code from vignettes Message-ID:
>> <538c0654.7050...@gmail.com> Content-Type: text/plain;
>> charset=ISO-8859-1; format=flowed On 02/06/2014, 1:41 PM, Carl Boettiger
>> wrote:
>>> > Thanks both for the replies.
>>> >
> 
>
>> You haven't been reading very carefully.  I saw several:  mine, Martin
>> Morgan's, Kasper Daniel Hansen's.
>>
>> Duncan Murdoch

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

Yes, I completely agree the tangle code should run without errors, if
the package author has provided such a script. However, I think it is
also the package author's right to choose not to provide such a
script, for reasons that I stated in the beginning (1. redundancy; 2.
tangle functions ignore inline expressions that should not be
ignored).

It seems that I still need to clarify it: I'm not talking about
disabling _running_ the tangled code, but disabling _generating_ the
code _optionally_. Unless someone is arguing that the tangled code
_must_ be generated from vignettes, I do not think anybody in this
discussion really has a conflict with anybody else.

Please also note that I do not expect R core or CRAN maintainers to do
any extra work: package authors can easily disable tangle by
themselves without anything special flags to R CMD build or R CMD
check. The vignettes are still built normally (in terms of "weave"). I
brought forward the discussion to hear the possible harm that I was
potentially not aware of when we disable tangle for R package
vignettes (e.g. does it affect the quality of the package?). So far I
have not heard real harm (I admit my judgment is subjective).

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Mon, Jun 2, 2014 at 10:19 AM, Paul Gilbert  wrote:
>
>
> On 06/02/2014 12:16 AM, Gabriel Becker wrote:
>>
>> Carl,
>>
>> I don't really have a horse in this race other than a strong feeling that
>> whatever check does should be mandatory.
>>
>> That having been said, I think it can be argued that the fact that check
>> does this means that it IS in the R package vignette specification that
>> all
>> vignettes must be such that their tangled code will run without errors.
>
>
> My understanding of this is that the package maintainer can turn off
> building the vignette (--no-vignettes) but R CMD check and CRAN still check
> that the tangle code runs, and the check fails if it does not. Running the
> tangle code can be turned off, just not by the package maintainer. You have
> to make a special appeal to the CRAN maintainers, and give reasons they are
> prepared to accept. I think the intention is that the tangle code should run
> without errors. I doubt they would accept "it doesn't work" as an acceptable
> reason. But there are reasons, like the vignette requires access to a
> commercial database engine. Also, I think, turning this off means they just
> do not run it regularly, in the daily checks. I don't think it necessarily
> means the code is never tested. The testing may need to be done on machines
> with special resources.
>
> Thus, --no-vignettes provides a mechanism to avoid running the tangle code
> twice but, without special exemption, it is still run once. Some package
> maintainers may not think of several feature of 'R CMD check' as 'aids'. I
> think of it having more to do with maintaining some quality assurance, which
> I think of as an aid but not a debugging aid.
>
> I believe the CRAN maintainers have intentionally, and successfully, made
> disabling the running of tangled code  more trouble than it is generally
> worth. Effectively, a package should have tangle code that runs without
> errors.
>
> (Of course, I could be wrong about all this, it has happened before.)
>
> Paul

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

1. The starting point of this discussion is package vignettes, instead
of R scripts. I'm not saying we should abandon R scripts, or all
people should write R code to generate reports. Starting from a
package vignette, you can evaluate it using a weave function, or
evaluate its derivative, namely an R script. I was saying the former
might not be a bad idea, although the latter sounds more familiar to
most R users. For a package vignette, within the context of R CMD
check, is it necessary to do tangle + evaluate _besides_ weave?

2. If you are comfortable with reading pure code without narratives,
I'm totally fine with that. I guess there is nothing to argue on this
point, since it is pretty much personal taste.

3. Yes, you are absolutely correct -- Sweave()/knit() does more than
source(), but let me repeat the issue to be discussed: what harm does
it bring if we disable tangle for R package vignettes?

Sorry if I did not make it clear enough, my priority of this
discussion is the necessity of tangle for package vignettes. After we
finish this issue, I'll be happy to extend the discussion towards
tangle in general.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Sat, May 31, 2014 at 9:20 PM, Gabriel Becker  wrote:
>
>
>
> On Sat, May 31, 2014 at 6:54 PM, Yihui Xie  wrote:
>
>> I agree that fully evaluating the code is valuable, but
>> it is not a problem since the weave functions do fully evaluate the
>> code. If there is a reason for why source() an R script is preferred,
>>
>> I guess it is users' familiarity with .R instead of .Rnw/.Rmd/...,
>
>
> It's because .Rnw and Rmd require more from the user than .R. Also, this
> started with vignettes but you seem to be talking more generally. If so, I
> would point out that not all R code is intended to generate reports, and
> writing pure R code that isn't going to generate a report in an .Rnw/.Rmd
> file would be very strange to say the least.
>
>
>>
>> however, I guess it would be painful to read the pure R script tangled
>> from the source document without the original narratives.
>
>
> That depends a lot on what you want. Reading an woven article/report that
> includes code and reading code are different and equally valid activities.
> Sometimes I really just want to know what the author actually told the
> computer to do.
>
>>
>>
>> So what do we really lose if we turn off tangle? We lose an R script
>> as a derivative from the source document, but we do not lose the code
>> evaluation.
>
>
> We lose *isolated* code evaluation. Sweave/knit have a lot more moving
> pieces than source/eval do. Many of which are  for the purpose of displaying
> output, rather than running code.
>

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

Yes, that is a matter of familiarity as I mentioned, isn't it? I
understand this justification. I can argue that it is also convenient
to give people an Rnw/Rmd document and they can easily run the R code
chunks as well (e.g. in RStudio, chunk navigation and evaluation are
pretty simple) _within_ the context of your teaching materials.
However, I think this is drifting away from the original topic, so
I'll stop my comments on the direction of teaching.

The original question was, what do we lose if we disable tangle for R
package vignettes? Please also note I mean this is _optional_, i.e.
package authors can _choose_ whether they want to disable tangle.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Sat, May 31, 2014 at 9:11 PM, Kasper Daniel Hansen
 wrote:
> The Bioconductor project has a substantial amount of teaching material in
> the form of Sweave files.  For teaching, it can be extremely convenient to
> give people an R script which they can copy and paste from (or do something
> else with).  This is especially true for inexperienced R users.
>
> Best,
> Kasper
>

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

I mentioned in my original post that Sweave()/knit()/... can be
considered as the "new" source(). They can do the same thing as
source() does. I agree that fully evaluating the code is valuable, but
it is not a problem since the weave functions do fully evaluate the
code. If there is a reason for why source() an R script is preferred,
I guess it is users' familiarity with .R instead of .Rnw/.Rmd/...,
however, I guess it would be painful to read the pure R script tangled
from the source document without the original narratives.

So what do we really lose if we turn off tangle? We lose an R script
as a derivative from the source document, but we do not lose the code
evaluation.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Sat, May 31, 2014 at 6:20 PM, Martin Morgan  wrote:
> On 05/31/2014 03:52 PM, Yihui Xie wrote:
>>
>> Note the test has been done once in weave, since R CMD check will try
>> to rebuild vignettes. The problem is whether the related tools in R
>> should change their tangle utilities so we can **repeat** the test,
>> and it seems the answer is "no" in my eyes.
>>
>> Regards,
>> Yihui
>> --
>> Yihui Xie 
>> Web: http://yihui.name
>>
>>
>> On Sat, May 31, 2014 at 4:54 PM, Gabriel Becker 
>> wrote:
>>>
>>>
>>>
>>>
>>> On Fri, May 30, 2014 at 9:22 PM, Yihui Xie  wrote:
>>>>
>>>>
>>>> Hi Kevin,
>>>>
>>>>
>>>> I tend to adopt Henrik's idea, i.e., to provide vignette
>>>> engines that just ignore tangle. At the moment, it seems R CMD check
>
>
> It is very useful, pedagogically and when reproducing analyses, to be able
> to source() the tangled .R code into an R session, analogous to running
> example code with example(). The documentation for ?Stangle does read
>
>  (Code inside '\Sexpr{}' statements is ignored by 'Stangle'.)
>
> So my 'vote' (recognizing that I don't have one of those) is to incorporate
> \Sexpr{} expressions into the tangled code, or to continue to flag use of
> Sexpr with side effects as errors (indirectly, by source()ing the tangled
> code), rather than writing engines that ignore tangle.
>
> It is very valuable to all parties to write a vignette with code that is
> fully evaluated; otherwise, it is too easy for bit rot to seep in, or to
> 'fake' it in a way that seems innocent but is misleading.
>
> Martin Morgan

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

Note the test has been done once in weave, since R CMD check will try
to rebuild vignettes. The problem is whether the related tools in R
should change their tangle utilities so we can **repeat** the test,
and it seems the answer is "no" in my eyes.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Sat, May 31, 2014 at 4:54 PM, Gabriel Becker  wrote:
>
>
>
> On Fri, May 30, 2014 at 9:22 PM, Yihui Xie  wrote:
>>
>> Hi Kevin,
>>
>>
>> I tend to adopt Henrik's idea, i.e., to provide vignette
>> engines that just ignore tangle. At the moment, it seems R CMD check
>> is comfortable with vignettes that do not have corresponding R
>> scripts, and I hope these R scripts will not become mandatory in the
>> future.
>
>
> I'm not sure this is the right approach. This would essentially make the
> test optional based on decisions by the package author. I'm not arguing in
> favor if this particular test, but if package authors are able to turn a
> test off then the test loses quite a bit of it's value.
>
> I think that R CMD check has done a great deal for the R community by
> presenting a uniform, minimum "barrier to entry" for R packages. Allowing
> package developers to alter the tests it does (other than the obvious case
> of their own unit tests) would remove that.
>
> That having been said, it seems to me that tangle-like utilities should have
> the option of extracting inline code, and that during R CMD check that
> option should *always* be turned on.  That would solve the problem in
> question while retaining the test would it not?
>
> ~G

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

Re: [Rd] R CMD check for the R code from vignettes

[Yihui Xie]

Hi Kevin,

Personally I also avoid code that have side effects in the inline
expressions, but I think there are legitimate use cases in which
inline expressions have side effects. This discussion was motivated by
Carl's knitcitations package, as well as another question on
StackOverflow (http://stackoverflow.com/q/23927325/559676).

I'm aware of the distinction between the original literate programming
paradigm and the one in R (that is why I said "literate programming in
R" instead of "literate programming in general"). In R, weave actually
does what both weave and tangle do in the original paradigm -- there
is no need to tangle the document to get the computer code so that we
can execute it.

To Carl: I agree that it is a little extreme to drop tangle entirely,
so I think at least knitr::purl() will stay there in the foreseeable
future. I tend to adopt Henrik's idea, i.e., to provide vignette
engines that just ignore tangle. At the moment, it seems R CMD check
is comfortable with vignettes that do not have corresponding R
scripts, and I hope these R scripts will not become mandatory in the
future.

Thanks everyone for your comments!

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Fri, May 30, 2014 at 8:21 AM, Kevin Coombes
 wrote:
> Hi,
>
> Unless someone is planning to change Stangle to include inline expressions
> (which I am *not* advocating), I think that relying on side-effects within
> an \Sexpr construction is a bad idea. So, my own coding style is to restrict
> my use of \Sexpr to calls of the form
> \Sexpr{show.the.value.of.this.variable}. As a result, I more-or-less believe
> that having R CMD check use Stangle and report an error is probably a good
> thing.
>
> There is a completely separate questions about the relationship between
> Sweave/Stangle or knit/purl and literate programming that is linked to your
> question about whether to use Stangle on vignettes. The underlying model(s)
> in R have drifted away from Knuth's original conception, for some good
> reasons.
>
> The original goal of literate programming was to be able to explain the
> algorithms and data structures in the code to humans.  For that purpose, it
> was important to have named code chunks that you could move around, which
> would allow you to describe the algorithm starting from a high level
> overview and then drilling down into the details. From this perspective,
> "tangle" was critical to being able to reconstruct a program that would
> compile and run correctly.
>
> The vast majority of applications of Sweave/Stangle or knit/purl in modern R
> have a completely different goal: to produce some sort of document that
> describes the results of an analysis to a non-programmer or
> non-statistician.  For this goal, "weave" is much more important than
> "tangle", because the most important aspect is the ability to integrate the
> results (figures, tables, etc) of running the code into the document that
> get passed off to the person for whom the analysis was prepared. As a
> result, the number of times in my daily work that I need to explicitly
> invoke Stangle (or purl) explicitly is many orders of magnitude smaller than
> the number of times that I invoke Sweave (or knitr).
>
>   -- Kevin
>
>
>
> On 5/30/2014 1:04 AM, Yihui Xie wrote:
>>
>> Hi,
>>
>> Recently I saw a couple of cases in which the package vignettes were
>> somewhat complicated so that Stangle() (or knitr::purl() or other
>> tangling functions) can fail to produce the exact R code that is
>> executed by the weaving function Sweave() (or knitr::knit(), ...). For
>> example, this is a valid document that can pass the weaving process
>> but cannot generate a valid R script to be source()d:
>>
>> \documentclass{article}
>> \begin{document}
>> Assign 1 to x: \Sexpr{x <- 1}
>> <<>>=
>> x + 1
>> @
>> \end{document}
>>
>> That is because the inline R code is not written to the R script
>> during the tangling process. When an R package vignette contains
>> inline R code expressions that have significant side effects, R CMD
>> check can fail because the tangled output is not correct. What I
>> showed here is only a trivial example, and I have seen two packages
>> that have more complicated scenarios than this. Anyway, the key thing
>> that I want to discuss here is, since the R code in the vignette has
>> been executed once during the weaving process, does it make much sense
>> to execute the code generated from the tangle function? In other
>> words, if the weaving process has succeeded, is it necessary to
>> source() the R script again?
>>
>> The two options here are:
&g

[Rd] R CMD check for the R code from vignettes

[Yihui Xie]

Hi,

Recently I saw a couple of cases in which the package vignettes were
somewhat complicated so that Stangle() (or knitr::purl() or other
tangling functions) can fail to produce the exact R code that is
executed by the weaving function Sweave() (or knitr::knit(), ...). For
example, this is a valid document that can pass the weaving process
but cannot generate a valid R script to be source()d:

\documentclass{article}
\begin{document}
Assign 1 to x: \Sexpr{x <- 1}
<<>>=
x + 1
@
\end{document}

That is because the inline R code is not written to the R script
during the tangling process. When an R package vignette contains
inline R code expressions that have significant side effects, R CMD
check can fail because the tangled output is not correct. What I
showed here is only a trivial example, and I have seen two packages
that have more complicated scenarios than this. Anyway, the key thing
that I want to discuss here is, since the R code in the vignette has
been executed once during the weaving process, does it make much sense
to execute the code generated from the tangle function? In other
words, if the weaving process has succeeded, is it necessary to
source() the R script again?

The two options here are:

1. Do not check the R code from vignettes;
2. Or fix the tangle function so that it produces exactly what was
executed in the weaving process. If this is done, I'm back to my
previous question: does it make sense to run the code twice?

To push this a little further, personally I do not quite appreciate
literate programming in R as two separate steps, namely weave and
tangle. In particular, I do not see the value of tangle, considering
Sweave() (or knitr::knit()) as the new "source()". Therefore
eventually I tend to just drop tangle, but perhaps I missed something
here, and I'd like to hear what other people think about it.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name

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

Re: [Rd] Latex errors (build on windows)

[Yihui Xie]

You do not need to feel so bad. No one was born an expert (even an
expert may not be able to find the relevant information in a
subsection of an appendix in a certain manual among numerous
hyperlinks). The sky is not going to falling down, and the earth is
not going to explode just because you do not know how to install a
LaTeX package. I'm pretty sure you are not the only one who was
puzzled by inconsolata.sty, and I believe this will continue to
confuse more in the future.

Unless one has LaTeX vignettes, the Rd PDF manual is normally the only
place where LaTeX is required in an R Package. Personally I do not
think this LaTeX dependency is worth it, comparing the relatively
small gain and the great effort to learn LaTeX as well as the
toolchain. It will be nice if the PDF manual can be optional for CRAN
and R CMD check. Biologists, doctors, and other scientists may spend
their time on more valuable things than learning LaTeX. Just my 2
cents.

P.S. Just in case this should be misunderstood: 1. I do appreciate the
value of LaTeX; 2. I'm grateful to the effort that R core made in the
manuals; 3. There are people who are busy with test tubes and
bacteria, and they also need sleep.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Sat, May 24, 2014 at 7:19 AM, Hualei Kong  wrote:
> Dear Prof Brian Ripley:
>  I am very sorry for that I use the unappropriate words "It's my great
> pleasure" when I read this mail again! I give my apology sincerely to you
> ,unreservedly and with my heart!
>  You are such a warm-hearted man.And you help me to solve my
> problems.But owing to  my poor English, I found I had made such a foolish
> mistake. My brain must have been stupid at that time . I hope you can
> forgive my carelessness and this will not affect your work.
>  I feel ashamed of myself.And this may be brought bad influences on my
> university as well as my country.I hope you won't have a bad impression on
> my country's students. From now on,aparting from learning R language,I will
> strengthen my English learning.And this will be a lesson for me.
>  Hope you could  forgive me! And I hope I can continue to learn from
> you.I request you can give me a chance,I will never make such a mistake !
>  Best wishes! I am looking forword to you reply!
>
>
>
> Hualei Kong

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

Re: [Rd] Bug in read.dcf(all = TRUE)?

[Yihui Xie]

Cc'ing Kurt since the version control history shows he brought it in a
few years ago: https://github.com/wch/r-source/commit/53d4b432f7

The fix can be fairly simple if someone has one minute:

lc_ctype <- Sys.getlocale("LC_CTYPE")
on.exit(Sys.setlocale("LC_CTYPE", lc_ctype), add = TRUE)
Sys.setlocale("LC_CTYPE", "C")

although I do not really understand why LC_CTYPE has to be changed to "C".

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Wed, May 14, 2014 at 4:34 PM, Yihui Xie  wrote:
> Hi,
>
> read.dcf() can modify the locale variable LC_CTYPE, and here is a
> minimal example:
>
>> Sys.getlocale('LC_CTYPE')
> [1] "en_US.UTF-8"
>> read.dcf(textConnection('a: b'), all = TRUE)
>   a
> 1 b
>> Sys.getlocale('LC_CTYPE')
> [1] "C"
>
> After diagnosing the problem, it seems the on.exit() call in
> read.dcf() is the culprit:
>
> on.exit(Sys.setlocale("LC_CTYPE", Sys.getlocale("LC_CTYPE")), add = TRUE)
> Sys.setlocale("LC_CTYPE", "C")
>
> https://github.com/wch/r-source/blob/96a2cc920/src/library/base/R/dcf.R#L68-L69
>
>> sessionInfo()
> R version 3.1.0 (2014-04-10)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> LC_TIME=en_US.UTF-8
>  [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
> LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> LC_ADDRESS=C
> [10] LC_TELEPHONE=C         LC_MEASUREMENT=en_US.UTF-8
> LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] tools_3.1.0
>
>
> Regards,
> Yihui
> --
> Yihui Xie 
> Web: http://yihui.name

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

[Rd] Bug in read.dcf(all = TRUE)?

[Yihui Xie]

Hi,

read.dcf() can modify the locale variable LC_CTYPE, and here is a
minimal example:

> Sys.getlocale('LC_CTYPE')
[1] "en_US.UTF-8"
> read.dcf(textConnection('a: b'), all = TRUE)
  a
1 b
> Sys.getlocale('LC_CTYPE')
[1] "C"

After diagnosing the problem, it seems the on.exit() call in
read.dcf() is the culprit:

on.exit(Sys.setlocale("LC_CTYPE", Sys.getlocale("LC_CTYPE")), add = TRUE)
Sys.setlocale("LC_CTYPE", "C")

https://github.com/wch/r-source/blob/96a2cc920/src/library/base/R/dcf.R#L68-L69

> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
LC_TIME=en_US.UTF-8
 [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=C

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

loaded via a namespace (and not attached):
[1] tools_3.1.0


Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name

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

Re: [Rd] The regular expressions in compareVersion()

[Yihui Xie]

You are right that this is unlikely to cause problems, because users
are unlikely to put backslashes in version numbers. Henrik has pointed
out the problem. It is not about "making the source code a little
cleaner", but "making it correct". Either someone in R core corrects
the wrong regular expressions in a few seconds (unless you think \ can
be a legal character in a version number), or I just give up the
report. It seems the latter is easier. It is not worth additional
Q&A's back and forth.

Regarding the regular expression problem for \Sexpr{} in Sweave,
please see here for a record:
http://r.789695.n4.nabble.com/Sweave-printing-an-underscore-in-the-output-from-an-R-command-td4675177.html
As I said, it is a similar problem: someone tried to escape a
character that did not need to be escaped in [].

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Thu, Apr 24, 2014 at 6:20 PM, Duncan Murdoch
 wrote:
> On 24/04/2014, 5:26 PM, Henrik Bengtsson wrote:
>>
>> On Thu, Apr 24, 2014 at 1:42 PM, Duncan Murdoch
>>  wrote:
>>>
>>> On 24/04/2014, 1:11 PM, Yihui Xie wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I guess the backslash should not be used as the separator for
>>>> strsplit() in compareVersion(), because the period in [.] is no longer
>>>> a metacharacter (no need to "escape" it using a backslash):
>>>>
>>>>
>>>> https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867
>>>>
>>>>> compareVersion
>>>>
>>>>
>>>> function (a, b)
>>>> {
>>>> 
>>>>   a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
>>>>   b <- as.integer(strsplit(b, "[\\.-]")[[1L]])
>>>> 
>>>> 
>>>
>>>
>>>
>>> Could you post an example where this causes trouble, or are you just
>>> suggesting this as a way to make the source a little cleaner?
>>
>>
>> Maybe it's already clear, but [\\.] is the set for the two symbols '\'
>> and '.', not '.' alone.  For example, I would expect an error below:
>>
>>> compareVersion("3.14-59.26", "3.14-59\\26")
>>
>> [1] 0
>>
>
> How does that cause problems?
>
> Duncan Murdoch
>
>
>> /Henrik
>>
>>>
>>>
>>>>
>>>> A similar regular expression problem also exists in the Sweave syntax
>>>> (for \Sexpr{}), and I have reported it once. It was fixed but the fix
>>>> was immediately reverted for some reason:
>>>>
>>>>
>>>> https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0
>>>
>>>
>>>
>>> A link to your report would be more useful, if it included an example
>>> where
>>> the bad regexp causes trouble.
>>>
>>> Duncan Murdoch

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

[Rd] The regular expressions in compareVersion()

[Yihui Xie]

Hi,

I guess the backslash should not be used as the separator for
strsplit() in compareVersion(), because the period in [.] is no longer
a metacharacter (no need to "escape" it using a backslash):
https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867

> compareVersion
function (a, b)
{

a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
b <- as.integer(strsplit(b, "[\\.-]")[[1L]])



A similar regular expression problem also exists in the Sweave syntax
(for \Sexpr{}), and I have reported it once. It was fixed but the fix
was immediately reverted for some reason:
https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name

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

Re: [Rd] Can the output of Sys.getenv() be improved?

[Yihui Xie]

For your first question, try str(as.list(Sys.getenv())). I do not know
the answer for the JAGS question, and I'll leave it to someone else to
tell you which mailing list to use for such questions...

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Fri, Apr 18, 2014 at 11:38 AM, Zhang,Jun  wrote:
> Within an R session, type Sys.getenv() will list all the environment 
> variables, but each one of them occupies about a page, so scrolling to find 
> one is difficult. Is this because I don't know how to use it or something 
> could be improved? Usually I'm not sure the exact name of a variable but want 
> to look it up. Recently I installed rjags, with the JAGS-3.4.0's lib, 
> include, modules information provided during compilation. When I load rjags, 
> I was told that it linked to JAGS 3.3.0 (a package also available in my 
> environment). This made me think there must be a variable to make that to 
> happen. What can I do to make rjags to link to JAGS 3.4.0?
>
> Jun

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

Re: [Rd] Package vignettes share the same environment?

[Yihui Xie]

By "quite slow" start-up time on Windows, you mean on the order of 1
or 2 seconds? That is probably not too bad, when we weigh it against
the confusion from compiling all vignettes in the same R session.

knitr::knit() has an 'envir' argument that specifies the environment
in which the code chunks are executed, but at the moment it is not
easy to pass additional arguments to the vignette engine. Of course,
one way is to define a new vignette engine, and that is not too hard:
it is basically something like knitr::knit(file, envir = new.env()).

But as mentioned below, there are other things shared in the same
session such as options(). I guess the cleanest way is still to start
new R sessions.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Sat, Apr 5, 2014 at 3:04 PM, Duncan Murdoch  wrote:
> On 05/04/2014, 2:24 PM, Martin Morgan wrote:
>>
>> In a package 'vig' R CMD build vig (or tools::buildVignettes(dir="vig")
>> with
>>
>> $ cat vig/vignettes/vig1.Rnw
>> \documentclass{article}
>> \begin{document}
>> <<>>=
>> x <- 1
>> @
>> \end{document}
>>
>> $ cat vig/vignettes/vig2.Rnw
>> \documentclass{article}
>> \begin{document}
>> <<>>=
>> x
>> @
>> \end{document}
>>
>> produces vig2.pdf where x is defined with value 1 -- the vignettes share a
>> build
>> environment. This seems undesirable in terms of reproducibility (a reader
>> of
>> vig2.pdf will not understand where x is assigned; similarly for the
>> results of
>> require()  or data() in vig1 referenced in vig2), and is not (?)
>> documented. A
>> more elaborate context is
>>
>>   https://stat.ethz.ch/pipermail/bioc-devel/2014-April/005501.html
>>
>> Would it be better to build each vignette in its own environment?
>
>
> It's not just the environment that gets shared:  if you run buildVignette or
> buildVignettes in an R session, other aspects of the session (e.g. options()
> settings) will also be inherited by the vignette.  The way "R CMD build"
> handles this is to start a new R process to build the vignettes.
>
> Currently it builds all vignettes in one process, rather than starting a
> separate process for each, which is why you see the x variable carry from
> one vignette to another.  I think it has been like this for quite a while,
> because on some platforms (e.g. Windows), starting a new process is quite
> slow.
>
> I don't know if any other packages than gage currently depend on this
> behaviour.  It does sound confusing for the reader, but I don't think it
> breaks reproducibility:  after all, if a user has the package, they have all
> the vignettes, not just one.  If they just have the vignette, then they
> might not have the functions in the package that it needs, so they've
> already lost reproducibility.
>
> Duncan Murdoch

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

Re: [Rd] Where to put package vignettes

[Yihui Xie]

It is not guaranteed that knitr vignettes will work for R < 3.0.x
(even with the Makefile approach, which was really a hack). Unless you
must stay with R 2.15.x, you are strongly recommended to upgrade to R
3.0.x and forget about the Makefile approach. Then follow the three
steps mentioned in http://yihui.name/knitr/demo/vignette/

If you still cannot work it out, please point us to the source of your package.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Thu, Feb 20, 2014 at 8:43 AM,   wrote:
> Dear Søren,
>
> Thank you very much for your answer, it solved my problem and now my
> package can be installed both on Linux and Windows and the vignette is
> available in both systems. I put the vignette in /vignettes.
>
> However, unfortunately my problems have not ended here. As mentioned, my
> vignette is built with knitr and with the following commands:
>
> 1) R CMD check foo
> 2) R CMD build foo
> 3) R CMD INSTALL foo_xxx.tar.gz
>
> the vignette is built with Sweave!
>
> I have read in http://yihui.name/knitr/demo/vignette/ that in that case,
> a Makefile should be incorporated.
>
> I have incorporated in /inst/doc the makefile from
> https://github.com/yihui/knitr/blob/7eb34104/inst/doc/Makefile
>
> however, my vignette is still built with Sweave. I use R 2.15.2.
>
> How can I fix this performance?.
>
> Thank you very much again.
>
> Best regards,
>
> Guillermo
>
>> My understanding is this:
>>
>> 1) Put vignettes files (.Rnw files) in the /vignettes subdirectory. 2)
> Build the package foo with R CMD build foo. 3) Install the package with
> R CMD INSTALL foo_xxx.tar.gz
>>
>> Then the vignettes will be available. However you can also install the
> package with R CMD INSTALL foo, but then the vignettes will *not* be
> available (because it is in the build process that the vignettes go from
> /vignettes to /inst/doc)
>>
>> Regards
>> Søren
>>
>>
>> -Original Message-
>> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of guillermo.vi...@uv.es
>> Sent: 20. februar 2014 12:19
>> To: r-devel@r-project.org
>> Subject: [Rd] Where to put package vignettes
>>
>> Dear R-devel list,
>>
>> My name is Guillermo Vinué. I have created an R package that includes
> a vignette. Earlier on, to test my package, I tried to install it both
> in Linux and Windows and it worked. My vignette was in /inst/doc.
>>
>> Now, I have finished for good and before submitting my package to CRAN
> I've tried to install it again first in Linux and then in Windows (I
> removed that first installation some time ago).
>>
>> My package was succesfully installed in Linux (Fedora 18 and R 2.15.2)
> and the vignette was available. However, when trying to install it in
> Windows (R 3.0.2), unfortunately the vignette didn't appear. My vignette
> is build with knitr.
>>
>> In fact, if I first install the package on Windows, the vignette is
> accesible, but then in Linux, not.
>>
>> I have read that as from R 2.14.0 the preferred location for the
> Sweave sources is the subdirectory vignettes of the source packages, but
> for compatibility with earlier versions of R, vignette sources will be
> looked for in inst/doc if vignettes does not exist.
>>
>> Where do I have to put my vignette so that it could be available with
> any installation and which files (.Rnw or .pdf) should be included?.
>>
>> I hope you can clarify my doubts. I have seen the collection of prior
> postings to the list, but I have not found a specifical answer to my
> doubts .
>>
>> Thank you very much in advance.
>>
>> Best regards,
>>
>> Guillermo

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

[Rd] Format an empty data frame

[Yihui Xie]

Hi,

Here seems to be a corner case in which format() fails:

> format(data.frame())
Error in .subset2(x, i, exact = exact) : subscript out of bounds

> sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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


Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name

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

Re: [Rd] cat with backspace and newline characters

[Yihui Xie]

Yes, that indeed sounds like a problem, but example(txtProgressBar),
which is based on \r, works well in the RStudio console. Anyway,
thanks for all the experiments, and (to Renaud) support.rstudio.org is
the place to report such problems.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Tue, Nov 5, 2013 at 4:57 PM, peter dalgaard  wrote:
>
>
> So in a sense, it is the prompt that is tweaked to “jump to beginning of next 
> line, unless already at beginning of line”. I don’t recall any “real” 
> terminal having an escape sequence for that, but I wouldn’t put it past ESS 
> to do something similar.
>
> I see your point about cat(“pi”, pi), but I would expect that the bad habit 
> would get cured first time it was attempted to print something between it and 
> the next prompt. I’m actually more worried/puzzled that “\r” behaves 
> strangely (in Rstudio, not R.app):
>
>> cat("123");cat("\r456")
> 456
>> cat("123\r");cat("456")
> 123456
>
> People do sometimes use this pattern for displaying progress (e.g. iteration 
> counts).
>

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

Re: [Rd] R CMD check problem with R 3.0.2

[Yihui Xie]

I understand these reasons, and they certainly make sense when a
package has a big/complicated src/ directory. Perhaps one day more
developers will move the building and checking to cloud services (e.g.
I have been using Travis CI), so nobody cares about the
building/checking time spent on local machines any more.

For now, I think either `R CMD check --build` (must build before
checking) or `R CMD check --force` (definitely check without building)
sounds like a reasonable solution.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Mon, Oct 28, 2013 at 12:40 PM, Martin Maechler
 wrote:
>>>>>> Duncan Murdoch 
>>>>>> on Sun, 27 Oct 2013 08:56:31 -0400 writes:
>
> > On 13-10-26 9:49 PM, Simon Urbanek wrote:
> >> On Oct 25, 2013, at 12:12 PM, Yihui Xie wrote:
> >>
> >>> This has been asked s many times that I think it may
> >>> be a good idea for R CMD check to just stop when the
> >>> user passes a directory instead of a tar ball to it, or
> >>> automatically run R CMD build before moving on. In my
> >>> opinion, sometimes an FAQ and a bug are not entirely
> >>> different.
> >>>
> >>
> >> +1 -- and I'd do the same for R CMD INSTALL. If someone
> >> insists, there could be --force or something like that
> >> for those that really want to work on directories despite
> >> all the issues with that, but IMHO the default should be
> >> for both INSTALL and check to bail out if not presented
> >> with a file -- it would save a lot of people a lot of
> >> time spent in chasing ghost issues.
>
> > That seems like a reasonable suggestion.  I wouldn't want
> > to lose the ability to install or check a directory; for
> > development of packages like rgl which have a lot of
> > compiled code, installing from a tarball takes a lot
> > longer than installing when all of the code has already
> > been compiled.
>
> Even more extreme for  Matrix, and as you mention other packages
> with a considerable portion of compiled code.
>
> R CMD build also does some checks that then are done again, when
> you  R CMD check the tarball.
> It really adds a considerable amount of time/work to have to do
> both and I'd strongl oppose to disable checking of the source
> directory of a package.
>
> Actually, I do think that the 'build/check' R code could and should be
> modularized so that checking a directory with an 'Authors@R' in DESCRIPTION
> ((and no 'Maintainer'/'Authors' as they are auto-created)) would
> still work fine...
>
>
> > On the other hand, it isn't all that hard to put together
> > an R function or shell script to do it (the hardest part
> > is figuring out the name of the tarball).  For example:
>
> > installpkgdir <- function(dir) {
> > x <- system(paste("R CMD build", dir), intern=TRUE)
> >  
> > }
>
> > I haven't tested this much, and it doesn't offer options
> > to the build or install steps, but it could be the basis
> > of a simple function that always builds a tarball before
> > installing a source directory.
>
> well, there have been other ways to bundle  "build + check", of
> course, but for some developers, package building really is not fast,
> notably for people like me with a large library of R packages,
> where the all dependent packages incl those in 'Suggests' are
> sought and checked for the correct version, etc.
> Also, by default the vignette rebuilding; manuals etc take time,
> and it used to need other manual manipulations if you disabled those,
> and then wanted to check the tarball.
>
> I'd be very much inconvenienced if I'd need to build packages
> every time I want to check them during development.  Things are
> different shortly before a release.
>
> Martin

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

Re: [Rd] appropriate work-around for problems with a specific plot device (Rstudio)?

[Yihui Xie]

You can see how R sets up the device option in grDevices:::.onLoad,
but unfortunately the code there is not easily usable.

I think you can treat the NOTE in R CMD check as a false warning and
explain the situation to CRAN maintainers in the email. Code analysis
using codetools in R CMD check is not always reliable. I'm not sure if
grDevices::quartz, grDevices::x11, and grDevices::windows can "fix"
the NOTE.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Fri, Oct 25, 2013 at 9:24 AM, Lorenz, David  wrote:
> Skye,
>   I ran into a similar problem with RStudio. My solution was just to check
> if "windows" exists and if it does, open windows, then check "quartz" and
> so forth. You can restrict the exists function to look only in grDevices.
> Dave
>
>
> On Fri, Oct 25, 2013 at 4:19 AM, Milan Bouchet-Valat wrote:
>
>> Le jeudi 24 octobre 2013 à 17:13 -0700, Skye Bender-deMoll a écrit :
>> > Dear r-devel-opers,
>> >
>> > I'm working on a package that does some plot-intensive work using the
>> > animation library.  It turns out that this performs very badly in the
>> > RStudio plot device, which is the preferred IDE for our team.  Our
>> > kludgy solution is to detect if the Rstudio device is running, and if
>> > so, open another plot device to do the rendering and close it when done:
>> >
>> > externalDevice<-FALSE
>> >if (!is.function(options()$device)){
>> >  if (names(dev.cur())=="RStudioGD"){
>> >message("RStudio's graphics device is not well supported by ndtv,
>> > attempting to open another type of plot window")
>> ># try to open a new platform-appropriate plot window
>> >if (.Platform$OS.type=='windows'){
>> >  windows()
>> >} else if(length(grep(R.version$platform,pattern='apple'))>0)  #
>> > is it mac?
>> >{
>> >  quartz()
>> >} else {  # must be unix
>> >  x11()
>> >}
>> >externalDevice<-TRUE
>> >  }
>> >}
>> >
>> > [render a whole bunch of plot frames]
>> >
>> > # turn off external device if using one
>> >if (externalDevice){
>> >  dev.off()
>> >}
>> >
>> > Although this works well for us in practice, when testing against R
>> > devel, we get the following NOTE:
>> >
>> >
>> > * checking R code for possible problems ... NOTE
>> > Found an obsolete/platform-specific call in the following function:
>> >‘render.animation’
>> > Found the platform-specific devices:
>> >‘quartz’ ‘windows’ ‘x11’
>> > dev.new() is the preferred way to open a new device, in the unlikely
>> > event one is needed.
>> >
>> >
>> > Is there a better way to resolve this situation?  We can't use dev.new()
>> > to open the plot device, because RStudio has set the value of
>> > getOption("device") to "RStudioGD".  Can anyone recommend an alternative
>> > method of generating a platform-appropriate device to open that won't
>> > generate R CMD check issues?
>> How about temporarily changing the value of the "device" option to what
>> you need?
>>
>> I think you should also get in touch with RStudio developers to see
>> whether something can be done about the poor performance.
>>
>>
>> My two cents

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

Re: [Rd] R CMD check problem with R 3.0.2

[Yihui Xie]

This has been asked s many times that I think it may be a good
idea for R CMD check to just stop when the user passes a directory
instead of a tar ball to it, or automatically run R CMD build before
moving on. In my opinion, sometimes an FAQ and a bug are not entirely
different.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Fri, Oct 25, 2013 at 10:37 AM, Sanford Weisberg  wrote:
> Using SUSE Linux, Windows 32 bit and Windows 64 bit R 3.0.2 , I am unable
> to use R CMD check successfully.  Here is the Windows 64 bit report:
>
>
> Z:\R\source\effects>R CMD check pkg
> * using log directory 'Z:/R/source/effects/pkg.Rcheck'
> * using R version 3.0.2 (2013-09-25)
> * using platform: x86_64-w64-mingw32 (64-bit)
> * using session charset: ISO8859-1
> * checking for file 'pkg/DESCRIPTION' ... ERROR
> Required fields missing or empty:
>   'Author' 'Maintainer'
>
> The file DESCRIPTION looks like this:
>
> Package: effects
> Version: 2.3-0
> Date: 2013/10/22
> Title: Effect Displays for Linear, Generalized Linear, Multinomial-Logit,
> Proportional-Odds Logit Models and Mixed-Effects Models
> Authors@R: c(person("John", "Fox", role = c("aut", "cre"), email = "
> j...@mcmaster.ca"),
> person("Sanford", "Weisberg", role = "aut", email = "sa...@umn.edu"),
> person("Michael", "Friendly", role = "aut", email = "frien...@yorku.ca
> "),
> person("Jangman", "Hong", role = "aut"),
> person("Robert", "Andersen", role = "ctb"),
> person("David", "Firth", role = "ctb"),
> person("Steve", "Taylor", role = "ctb"))
> Depends: lattice, grid, colorspace
> Suggests: nlme, lme4, MASS, nnet, poLCA, heplots
> LazyLoad: yes
> LazyData: yes
> Description:
>   Graphical and tabular effect displays, e.g., of interactions, for linear
>   generalized linear, multinomial-logit, proportional-odds logit models,
>   mixed-effect models,  polytomous latent-class models and multivariate
> linear models.
> License: GPL (>= 2)
> URL: http://www.r-project.org, http://socserv.socsci.mcmaster.ca/jfox/
>
> The 'Author' and 'Maintainer' fields should be automatically generated.
> With version 3.0.1, I had no such problem, and my coauthors who use Eciplse
> and R-studio have no problems with R 3.0.2.  John Fox suggested the
> following:
>
> When R CMD build creates a package tarball it writes the information from
> Authors@R into the
> Author and Maintainer fields. I think that Sandy's
> problem is produced by checking the package source directory rather than a
> package source tarball. I use RStudio to check packages, and it
> automatically builds the tarball first, which is the recommended procedure.
> R-Forge does that too. Michael uses Eclipse, and if I remember right, it too
> creates a tarball (but I haven't used it in quite some time).
>
> Is this a bug in R CMD check?
>
>
> --
> Sanford Weisberg, sa...@umn.edu
> 
> For undergraduate matters:  underg...@stat.umn.edu
> University of Minnesota, School of Statistics
> 312 Ford Hall, 224 Church St. SE, Minneapolis, MN  55455
> 612-625-8355, FAX 612-624-8868
>
> [[alternative HTML version deleted]]
>
> __
> 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] png(type='cairo'): point symbols without boarders are not anti-aliased?

[Yihui Xie]

Thanks for the hints! I was originally wondering the difference
between grDevices::png(type='cairo') and Cairo::CairoPNG() for the
case pch=16, a solid point without border. Cairo does a nice job for
such point symbols, but png() renders them very poorly.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Tue, Oct 22, 2013 at 9:09 AM, Simon Urbanek
 wrote:
> The Cairo package does "smart" anti-aliasing - it aligns lines that are 
> perpendicular to the axes such that they centered at pixels. That avoids the 
> anti-aliasing effects that Brian was talking about for the heatmap example. 
> This enables Cairo to have full anti-aliasing support and still render 
> heatmaps without artifacts.
>
> However, there is no way around the anti-aliasing artifacts if you use 
> arbitrary polygons without borders. For example:
>
> library(deldir)
> plot(c(-1,1),c(-1,1),ty='n')
> for(p in tile.list(deldir(rnorm(200),rnorm(200 
> polygon(p$x,p$y,col=heat.colors(15)[runif(1,1,15)], border=NA)
>
> That said, in our experience the Cairo approach works very well in practice.
>
> Cheers,
> Simon

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

Re: [Rd] png(type='cairo'): point symbols without boarders are not anti-aliased?

[Yihui Xie]

Perhaps yes. Sorry I did not check the bug reports. Can someone
elaborate on the "undesirable artefacts"? I made two heatmaps using
png() and CairoPNG(), respectively. I can see the difference, but it
is not very clear to me what the artefacts are, or what the facts
should be.

png(): http://i.imgur.com/lKrFG9i.png
CairoPNG(): http://i.imgur.com/Dv0rsKK.png

f = function(dev, ...) {
  dev(...)
  x = y <- seq(-4*pi, 4*pi, len = 27)
  r = sqrt(outer(x^2, y^2, "+"))
  z = cos(r^2)*exp(-r/6)
  image(z, main = deparse(substitute(dev)))
  dev.off()
}
f(grDevices::png, 'png-base.png', type = 'cairo')
f(Cairo::CairoPNG, 'png-Cairo.png')

Thanks!

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Mon, Oct 21, 2013 at 5:28 PM, Paul Murrell  wrote:
> Hi
>
> Is this the same as "Bug 15462" ?
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15462
>
> Paul
>
>
> On 10/22/13 10:43, Yihui Xie wrote:
>>
>> Hi,
>>
>> It seems that anti-aliasing in png(type = 'cairo') is not well
>> supported for the point symbols without boarders, e.g. pch = 16. The
>> Cairo package works well, though. You can compare png() with
>> CairoPNG():
>>
>> png(): http://i.imgur.com/8niB3jX.png
>> CairoPNG(): http://i.imgur.com/FZBJOxm.png
>>
>> f = function(dev, ..., main = '') {
>>dev(...)
>>plot(c(1, 2, 1, 2), c(1, 1, 2, 2), pch=c(16, 19), cex=c(2, 2, 15, 15),
>> xlim=c(0.5, 2.5), ylim=c(0.5, 3), main = deparse(substitute(dev)))
>>dev.off()
>> }
>> f(grDevices::png, 'png-base.png', type = 'cairo')
>> f(Cairo::CairoPNG, 'png-Cairo.png')
>>
>> If I remove the border for pch=19 (i.e. lwd=0), the point shows rough
>> edges as well.
>>
>> I'm not sure if that is expected, or it is due to my misconfiguration
>> somewhere. I installed R via `apt-get install r-base-dev` under Ubuntu
>> using the CRAN repository.
>>
>>> sessionInfo()
>>
>> R version 3.0.2 (2013-09-25)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>> locale:
>>   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>> LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>>   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>> LC_PAPER=en_US.UTF-8   LC_NAME=C
>>   [9] LC_ADDRESS=C   LC_TELEPHONE=C
>> LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] Cairo_1.5-2 tools_3.0.2
>>
>>> capabilities()
>>
>>  jpeg  png tifftcltk  X11 aqua http/ftp  sockets
>>  TRUE TRUE TRUE TRUE TRUEFALSE TRUE TRUE
>>libxml fifo   clediticonv  NLS  profmemcairo
>>  TRUE TRUE TRUE TRUE TRUE TRUE TRUE

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

Re: [Rd] png(type='cairo'): point symbols without boarders are not anti-aliased?

[Yihui Xie]

Sorry, typo in the subject: I mean "borders".

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Mon, Oct 21, 2013 at 4:43 PM, Yihui Xie  wrote:
> Hi,
>
> It seems that anti-aliasing in png(type = 'cairo') is not well
> supported for the point symbols without boarders, e.g. pch = 16. The
> Cairo package works well, though. You can compare png() with
> CairoPNG():
>
> png(): http://i.imgur.com/8niB3jX.png
> CairoPNG(): http://i.imgur.com/FZBJOxm.png
>
> f = function(dev, ..., main = '') {
>   dev(...)
>   plot(c(1, 2, 1, 2), c(1, 1, 2, 2), pch=c(16, 19), cex=c(2, 2, 15, 15),
>xlim=c(0.5, 2.5), ylim=c(0.5, 3), main = deparse(substitute(dev)))
>   dev.off()
> }
> f(grDevices::png, 'png-base.png', type = 'cairo')
> f(Cairo::CairoPNG, 'png-Cairo.png')
>
> If I remove the border for pch=19 (i.e. lwd=0), the point shows rough
> edges as well.
>
> I'm not sure if that is expected, or it is due to my misconfiguration
> somewhere. I installed R via `apt-get install r-base-dev` under Ubuntu
> using the CRAN repository.
>
>> sessionInfo()
> R version 3.0.2 (2013-09-25)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] Cairo_1.5-2 tools_3.0.2
>
>> capabilities()
> jpeg  png tifftcltk  X11 aqua http/ftp  sockets
> TRUE TRUE     TRUE     TRUE TRUEFALSE TRUE TRUE
>   libxml fifo   clediticonv  NLS  profmemcairo
> TRUE TRUE TRUE TRUE TRUE TRUE TRUE
>
>
> Regards,
> Yihui
> --
> Yihui Xie 
> Web: http://yihui.name
> Department of Statistics, Iowa State University
> 2215 Snedecor Hall, Ames, IA

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

[Rd] png(type='cairo'): point symbols without boarders are not anti-aliased?

[Yihui Xie]

Hi,

It seems that anti-aliasing in png(type = 'cairo') is not well
supported for the point symbols without boarders, e.g. pch = 16. The
Cairo package works well, though. You can compare png() with
CairoPNG():

png(): http://i.imgur.com/8niB3jX.png
CairoPNG(): http://i.imgur.com/FZBJOxm.png

f = function(dev, ..., main = '') {
  dev(...)
  plot(c(1, 2, 1, 2), c(1, 1, 2, 2), pch=c(16, 19), cex=c(2, 2, 15, 15),
   xlim=c(0.5, 2.5), ylim=c(0.5, 3), main = deparse(substitute(dev)))
  dev.off()
}
f(grDevices::png, 'png-base.png', type = 'cairo')
f(Cairo::CairoPNG, 'png-Cairo.png')

If I remove the border for pch=19 (i.e. lwd=0), the point shows rough
edges as well.

I'm not sure if that is expected, or it is due to my misconfiguration
somewhere. I installed R via `apt-get install r-base-dev` under Ubuntu
using the CRAN repository.

> sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

loaded via a namespace (and not attached):
[1] Cairo_1.5-2 tools_3.0.2

> capabilities()
jpeg  png tifftcltk  X11 aqua http/ftp  sockets
TRUE TRUE TRUE TRUE TRUEFALSE TRUE TRUE
  libxml fifo   clediticonv  NLS  profmemcairo
TRUE TRUE TRUE     TRUE TRUE TRUE TRUE


Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

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

Re: [Rd] user defined macros in Rd files

[Yihui Xie]

I mean, it sounds like a better idea to define \CRANpkg only once in
one central place, and use it in base R, instead of defining it in
every single Rd file, because it seems to be generally useful (is 91 a
large number? maybe).

Similarly, when it comes to an add-on package, it will be nice if the
package author can define these macros in one place, and use them in
his/her package.

When we have to copy and paste a macro 91 times, it seems to have
defeated the purpose of a macro.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Oct 9, 2013 at 3:55 PM, Duncan Murdoch  wrote:
> On 13-10-09 4:34 PM, Yihui Xie wrote:
>>
>> +1. As an example, there are 91 instances of \newcommand{\CRANpkg} in
>> R source, and this number is still growing as I see:
>>
>> $ grep "newcommand{CRANpkg}" -r . | wc
>>   91  91   10317
>>
>
> So you're saying if I ever get around to doing this, I'll have to track down
> 91+ files to make use of it?  This sounds like an argument why someone else
> should do it. ;-)
>
> Duncan Murdoch
>

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

Re: [Rd] user defined macros in Rd files

[Yihui Xie]

+1. As an example, there are 91 instances of \newcommand{\CRANpkg} in
R source, and this number is still growing as I see:

$ grep "newcommand{CRANpkg}" -r . | wc
 91  91   10317

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Oct 9, 2013 at 2:57 PM, Kasper Daniel Hansen
 wrote:
> R-exts, in "2.13 User-defined macros", discusses user-defined macros.  Is
> it possible to have macros defined in one file, be used by another (within
> a package)?  This would increase the usefulness substantially, IMHO.
>
> Best,
> Kasper

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

Re: [Rd] Error in "Writing R Extensions"

[Yihui Xie]

The double colon :: can be confusing here, but the R-exts manual is
actually correct. :: does not imply anything about the package
namespace; it is merely a separator. The vignette engines are written
in the form package::engine, and the engine name _happens_ to be
"knitr" as well in this case.

> library(knitr)
> str(tools::vignetteEngine(name='knitr', package='knitr'))
List of 5
 $ name   : chr "knitr"
 $ package: chr "knitr"
 $ pattern: chr "[.]([rRsS](nw|tex)|[Rr](md|html|rst))$"
 $ weave  :function (file, driver, syntax, encoding = "", quiet = FALSE, ...)
 $ tangle :function (file, driver, syntax, encoding = "", quiet = FALSE, ...)

I admit the engine name "knitr" is also confusing. There are other
engine names in knitr, though. For example, knitr::docco_classic
http://cran.r-project.org/web/packages/knitr/vignettes/docco-classic.html

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Oct 2, 2013 at 9:24 PM, John Maindonald
 wrote:
> In Section 1.4.2 of "Writing R Extensions"
>  %\VignetteEngine{knitr::knitr}
> should be
>  %\VignetteEngine{knitr::knit}
>
>> sessionInfo()
> R version 3.0.2 (2013-09-25)
> Platform: x86_64-apple-darwin10.8.0 (64-bit)
>
> Is this sort of thing best reported here, or is a huge report in order?
>
> John Maindonald email: john.maindon...@anu.edu.au
> phone : +61 2 (6125)3473fax  : +61 2(6125)5549
> Centre for Mathematics & Its Applications, Room 1194,
> John Dedman Mathematical Sciences Building (Building 27)
> Australian National University, Canberra ACT 0200.

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

[Rd] getParseData() for imaginary numbers

[Yihui Xie]

Hi,

The imaginary unit is gone in the 'text' column in the returned data
frame from getParseData(), e.g. in the example below, perhaps the text
should be 1i instead of 1:

> p=parse(text='1i')
> getParseData(p)
  line1 col1 line2 col2 id parent token terminal text
1 11 12  1  2 NUM_CONST TRUE1
2 11 12  2  0  exprFALSE
> sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=C LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

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

Re: [Rd] declaring package dependencies

[Yihui Xie]

I've been watching this thread closely and trying not to chime in,
because as Brian Rowe mentioned about CRAN's mysterious absence in a
previous reply. CRAN is like a ghost in r-devel (or any other mailing
lists) -- everybody is discussing about it, and nobody has ever seen
it. Perhaps one day useRs will realize that the rings of Saturn are
actually composed of the lost discussions about CRAN. (Just kidding.
No offence. I swear I appreciate the great work of CRAN, and
rep("thank you, CRAN", 1e6).)

Although this discussion may also contribute to the rings of Saturn, I
want to emphasize one final point: requests from package authors do
not necessarily mean more work for CRAN.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sun, Sep 15, 2013 at 6:11 PM, Ben Bolker  wrote:
> Matthew Dowle  mdowle.plus.com> writes:
>
>>
>>
>> I'm a little surprised by this thread.
>>
>> I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and
>> that's been pretty informative in the past :
>> http://developer.r-project.org/RSSfeeds.html
>>
>> Mainly though, I submit to winbuilder before submitting to CRAN, as the
>> CRAN policies advise.  winbuilder's R-devel seems to be built daily,
>> saving me the time. Since I don't have Windows it kills two birds with
>> one stone.  It has caught many problems for me before submitting to CRAN
>> and I can't remember it ever not responding in a reasonable time.
>> http://win-builder.r-project.org/upload.aspx
>>
>> I've suggested before that winbuilder could be the mechanism to submit
>> to CRAN rather than an ftp upload to incoming.  Only if winbuilder
>> passed OK on R-devel could it then go to a human.   But iirc there was a
>> technical difficulty preventing this.
>>
>> Matthew
>
>   I was planning to write a careful e-mail to CRAN suggesting
> essentially this, and I may yet do so, but for now I'll just chime in
> and "+1" this.  Yihui Xie made a very similar suggestion sometime
> last year (I think).  It would seem so much easier for everyone,
> package maintainers *and* CRAN maintainers, to have an automatic
> filter of this sort, and I can't figure out any downside other than
> needing slightly more computer power (which surely must be a reasonable
> tradeoff for fewer human resources!), *if* having the
> auto-filter made people sloppier about checking before submitting.
>Do you happen to remember what the technical difficulty was?
> If I were a CRAN maintainer (thank goodness I'm not!), overcoming
> it would be one of my top priorities ...
>
>   Ben Bolker

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

Re: [Rd] ‘:::’ call

[Yihui Xie]

If this issue is going to be solved at all, it might end up as yet
another "hack" like utils::globalVariables just to "fix" R CMD check
which was trying to fix things that were not necessarily broken.

To be clear, I was not suggesting subvert this check. What I was
hoping is a way to tell CRAN that "Yes, I have read the documentation;
I understand the risk, and I want to take it like a moth flying into
the flames".

Many people have been talking about this "risk", and how about some
evidence? Who was bitten by :::? How many real cases in which a
package was broken by :::?

Yes, unexported functions may change, so are exported functions (they
may change API, be deprecated, add new arguments, change defaults, and
so on). Almost everything in a package is constantly evolving, and I
believe the correct way (and the only way) to stop things from being
broken is to write enough test cases. When something is broken, we
will be able to know that. Yes, we may not have control over other
people's packages, but we always have control over our own test cases.
IMHO, testing is the justification of CRAN's reputation and quality,
and that is a part of what CRAN does.

In God we trust, and everyone else should bring tests.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Aug 28, 2013 at 1:50 PM, Paul Gilbert  wrote:
> On 13-08-28 12:29 PM, Marc Schwartz wrote:
>>
>>
>> On Aug 28, 2013, at 11:15 AM, Paul Gilbert  wrote:
>>
>>> I have a package (TSdbi) which provides end user functions that I export,
>>> and several utilities for plugin packages (e.g. TSMySQL) that I do not
>>> export because I do not intend them to be exposed to end users. I call these
>>> from the plugin packages using TSdbi:::  but that now produces a note in the
>>> checks:
>>>
>>> * checking dependencies in R code ... NOTE
>>> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>>>   See the note in ?`:::` about the use of this operator. :: should be
>>>   used rather than ::: if the function is exported, and a package
>>>   almost never needs to use ::: for its own functions.
>>>
>>> Is there a preferred method to accomplish this in a way that does not
>>> produce a note?
>>>
>>> Thanks,
>>> Paul
>>
>>
>>
>>
>> Paul,
>>
>> See this rather lengthy discussion that occurred within the past week:
>>
>>https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html
>>
>> Regards,
>>
>> Marc Schwartz
>
>
> I did follow the recent discussion, but no one answered the question "Is
> there a preferred method to accomplish this?" (I suppose the answer is that
> there is no other way, given that no one actually suggested anything else.)
> Most of the on topic discussion in that thread was about how to subvert the
> CRAN checks, which is not what I am trying to do and was also pointed out as
> a bad idea by Duncan. The substantive response was
>
>>r63654 has fixed this particular issue, and R-devel will no longer
>>warn against the use of ::: on packages of the same maintainer.
>>
>>Regards,
>>Yihui
>
> but that strikes me as a temporary work around rather than a real solution:
> suppose plugins are provided by a package from another maintainer.
>
> Since CRAN notes have a habit of becoming warnings and then errors, it seems
> useful to identify the preferred legitimate approach while this is still a
> note. That would save work for both package developers and CRAN maintainers.
>
> My thinking is that there is a need for a NAMESPACE directive something like
> limitedExport() that allows ::: for identified functions without provoking a
> CRAN complaint when packages use those functions. But there may already be a
> better way I don't know about. Or perhaps the solution is to split the end
> user functions and the utilities for plugin packages into two separate
> packages?
>
> Paul

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

Re: [Rd] legitimate use of :::

[Yihui Xie]

I know it is really bad, but the so-called good approach can be more
expensive than that, primarily because a package with a NOTE in R CMD
check is likely to be rejected by CRAN, or authors have to justify the
NOTE in the email.

For this particular case, I can imagine at least one case which can be
endless trouble to CRAN: if the package author A has talked to B to
use a hidden function in B's package, and B thinks that function is
relatively stable but does not want to export it; A may go ahead and
use it via :::. Both A and B understand that unexported function well,
then what should A do when submitting the package to CRAN? Should CRAN
continue adding rules for such exceptions?

In other words, "bad" practices almost always have exceptions and edge
cases. Of course, the decision is always in CRAN's hands, and I will
try to respect and follow it as a package author.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA


On Fri, Aug 23, 2013 at 11:05 AM, Duncan Murdoch
 wrote:
> On 13-08-22 11:54 PM, Yihui Xie wrote:
>>
>> Maybe it is not a good idea for R CMD check to check ::: at all, and a
>> warning in R-exts and ?':::' may well be enough. On the other hand, it
>> is just so easy to get around :::, because everybody can see its
>> source code:
>
>
> It's a really bad idea to write tricky code to subvert the tests.  If the
> tests are wrong, you can argue for changes (and in this case you did, and
> changes were made), but if you can't give a convincing argument, you should
> follow the good practices that the repository policies enforce.
>
> Duncan Murdoch
>
>>
>>> `:::`
>>
>> function (pkg, name)
>> {
>>  pkg <- as.character(substitute(pkg))
>>  name <- as.character(substitute(name))
>>  get(name, envir = asNamespace(pkg), inherits = FALSE)
>> }
>>
>> Then the package authors who really want to take the risk may start
>> another "hide and seek" game, e.g.
>>
>> `%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg),
>> inherits = FALSE)
>> 'stats' %:::% 'Pillai'

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

Re: [Rd] packages with Sweave and knitr vignettes?

[Yihui Xie]

Note there is a bug in R-release, and its consequence is that you
cannot use two different weave engines on two documents of the same
file extension.  In your case, you cannot use both knitr and Sweave on
two .Rnw documents. I just checked R-devel, and it has not been fixed
yet. If you do not have a good reason to use both engines, you can
just choose one of them.

Other than that, I think the non-Sweave vignettes are in a pretty good
state now.

You can check the Reverse Suggests on CRAN:
http://cran.r-project.org/package=knitr Most of them suggested knitr
for vignette building purposes, and knitr itself also uses knitr to
build LaTeX, HTML, and Markdown vignettes.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA


On Fri, Aug 23, 2013 at 4:49 PM, Henrik Bengtsson  wrote:
> On Fri, Aug 23, 2013 at 1:24 PM, Michael Friendly  wrote:
>> Now that R 3.0.0+ supports non-Sweave vignettes, R-exts \S 1.4.2 seems to
>> imply that
>> it is possible to include both Sweave and knitr vignettes in a single
>> package.
>>
>> I'm wondering
>> if anyone has tried this and/or if there are some hidden gotchas putting
>> this into practice,
>> and concerned about creating problems with CRAN checks if I try this.
>>
>> Consider two vignettes:
>>
>> pkg/vignettes/vign1.Rnw, containing:
>> % !Rnw weave = Sweave
>> %\VignetteEngine{Sweave}
>> ...
>>
>> pkg/vignettes/vign2.Rnw, containing:
>> % !Rnw weave = knitr
>> %\VignetteEngine{knitr::knitr}
>> ...
>>
>> both are .Rnw files, distinguished only by \VignetteEngine. vign1.Rnw is
>> currently in my
>> package, and vign2.Rnw compiles OK outside it, using knitr in an R console
>> or RStudio.
>>
>> R-exts implies that the DESCRIPTION file must include (minimally):
>>
>> VignetteBuilder: Sweave, knitr
>> Suggests: knitr
>
> The vignette-builder package for Sweave is 'utils' (not Sweave), so you want:
>
> VignetteBuilder: utils, knitr
>
> However, as said in 'Writing R Extensions', "The utils package is
> always implicitly appended to the list of builder packages.", so you
> don't really need to add it, but personally I'd say it's a nice
> gesture to make it explicit which vignette-builder package you are
> using.
>
> Also, the full formal engine name for Sweave is utils::Sweave, so for
> complete parallelism with knitr::knitr, you could be explicit and
> write \VignetteEngine{utils::Sweave}.
>
> /Henrik
>
>>
>> Is anything more/different required?  Does a package exist that does this?
>>
>> TIA
>> -Michael
>>
>> --
>> Michael Friendly Email: friendly AT yorku DOT ca
>> Professor, Psychology Dept. & Chair, Quantitative Methods
>> York University  Voice: 416 736-2100 x66249 Fax: 416 736-5814
>> 4700 Keele StreetWeb:   http://www.datavis.ca
>> Toronto, ONT  M3J 1P3 CANADA

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

Re: [Rd] legitimate use of :::

[Yihui Xie]

Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:

> `:::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}

Then the package authors who really want to take the risk may start
another "hide and seek" game, e.g.

`%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg),
inherits = FALSE)
'stats' %:::% 'Pillai'

Non-exported functions do not necessarily imply instability. Maybe it
is just because the author is too lazy to document them, or he/she did
not realize these functions happen to be useful for another author.

Although R-devel does not warn against ::: on the packages of the same
maintainer now, these maintainers may change in the future, or one
maintainer can be an author but not maintainer of another package,
from which he/she imports an unexported function, or package authors
have coordinated well with each other about the unexported functions.
I believe there are other legitimate reasons for :::, which might make
it difficult for R to cover all these cases, and also bring additional
communications between package authors and CRAN.

In conclusion, R CMD check cannot really stop :::, and ::: can be
there for good reasons, so how about just let it go?

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA


On Thu, Aug 22, 2013 at 9:02 PM, Gabriel Becker  wrote:
> Hey guys,
>
> Because I was curious and had nothing else that I should have been doing
> (that second part is a lie), I looked into the namespace code.
>
> I have a working patch that implements importHiddenFrom. It doesn't
> currently check whether you then export that symbol (which should not be
> allowed) but that would be easy to implement.
>
> Is there any desire from R-core to have add the importHiddenFrom
> functionality? If so I can add the export check and submit the patch either
> here or on bugzilla. I figure its a long shot but hey, at least I now know
> how the namespace stuff works.
>
> I do agree with Peter Meilstrup that poking around at the internals of
> someone else's code is often not a good idea, but as others have pointed
> out it is done in practice in some fairly high-profile packages, and if its
> going to happen it seems like it would be nice to indicate as much in the
> NAMESPACE file.
>
> ~G
>
>
> On Thu, Aug 22, 2013 at 5:41 PM, Gray  wrote:
>
>> Peter Meilstrup: (05:01PM on Thu, Aug 22)
>>
>>  One most often encounters namespace conflicts at the user level, when
>>> loading two packages that have no logical connection other than both
>>> bearing on your problem of the moment.
>>>
>>
>> Unless I'm mistaken, you can reassign the hidden functions, ie
>>
>> fna <- joespackage:::usefulfunction
>>
>> fnb <- janespackage:::usefulfunction
>>
>> which is a little bit of a pain, but makes the user's code
>> unambiguous.  This also works with two colons for explicitly exported
>> functions.
>>
>> --
>> Gray Calhoun, Assistant Professor of Economics at Iowa State
>> http://gray.clhn.co (web)

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

Re: [Rd] legitimate use of :::

[Yihui Xie]

r63654 has fixed this particular issue, and R-devel will no longer
warn against the use of ::: on packages of the same maintainer.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA


On Thu, Aug 22, 2013 at 6:45 AM, Uwe Ligges
 wrote:
>
>
> On 22.08.2013 07:45, Yihui Xie wrote:
>>
>> Hi,
>>
>> So now R CMD check starts to warn against :::, but I believe sometimes
>> it is legitimate to use it when developing R packages. For example, I
>> have some utils functions that are not exported but I want to share
>> them across the packages that I maintain. I do not need to coordinate
>> with other authors about these internal functions since I'm the only
>> author and I know clearly what I'm doing, and I want to avoid copying
>> and pasting the code across packages just to avoid the NOTE in R CMD
>> check. What should I do in this case?
>
>
> Nothing. The way you describe above seems to be a reasonable usage, iff you
> are the same maintainer who knows what is going on. Other maintainers should
> not use one of your not exported (hence non API) functions, of course.
>
> Uwe Ligges

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

[Rd] legitimate use of :::

[Yihui Xie]

Hi,

So now R CMD check starts to warn against :::, but I believe sometimes
it is legitimate to use it when developing R packages. For example, I
have some utils functions that are not exported but I want to share
them across the packages that I maintain. I do not need to coordinate
with other authors about these internal functions since I'm the only
author and I know clearly what I'm doing, and I want to avoid copying
and pasting the code across packages just to avoid the NOTE in R CMD
check. What should I do in this case?

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA

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

Re: [Rd] SweaveParseOptions, quoted commas, and knitr vignettes

[Yihui Xie]

Here is my understanding:

Package vignettes are built through tools::buildVignettes, which first
calls tools::pkgVignettes() to list the vignettes. Due to
loadVignetteBuilder(dir, mustwork = FALSE) in pkgVignettes(), the
vignette engine falls back to utils::Sweave if the specified vignette
builder was not found (in your case, knitr). Then because Sweave
cannot process knitr's Rnw files, the real problem goes under the
disguise of SweaveParseOptions(), which actually came from mustwork =
FALSE.

I think we discussed this issue (offline) before the non-Sweave engine
was introduced in R 3.0.0: if knitr is only required for package
vignettes, should it be specified in Depends/Imports or Suggests? The
former will make sure the vignettes always work because knitr will
always be installed, but if the user installs a prebuilt binary
package from, say, CRAN, he/she does not really need knitr to be
installed, as R will not rebuild the vignettes when installing the
binary packages. Later we decided to go with Suggests only, so that at
least R CMD check will work.

Two approaches to solve the problem:

1. either you Depends on knitr,
2. or make install.packages() also install VignetteBuilder (specified
in DESCRIPTION) when the user chooses to install from source, i.e.
install.packages(..., type = 'source')

I guess 1 is not a good choice.

Or if you want a less cryptic error message, put a code chunk like
this in your Rnw document:

<>=
library(knitr)
@

I think R will emit an error that knitr was not installed, which can
be more helpful for the users to realize the real problem.

Regards,
Yihui
--
Yihui Xie 
Phone: 206-667-4385 Web: http://yihui.name
Fred Hutchinson Cancer Research Center, Seattle


On Tue, Jul 16, 2013 at 7:34 PM, Ben Bolker  wrote:
>
>   I haven't figured it out entirely, but it looks like there are a
> couple of small glitches with knitr-based vignettes and
> SweaveParseOptions.
>
>   I posted the tarball of a package with a knitr vignette with (as far
> as I can tell) everything properly coded in the DESCRIPTION file
> (VignetteBuilder: knitr, Suggests: knitr) and the vignette itself
> (%\VignetteEngine{knitr::knitr}).  When Windows users (who may not
> have had knitr installed) tried to install it from source, they
> encountered an error from utils:::SweaveParseOptions .
>   The proximal source of the problem was a chunk header of the form
> <>= ; this is
> legal knitr, but doesn't make it through SweaveParseOptions because
> the function just splits on a comma without trying to check for
> nesting within quotation marks.
>   The second problem is that for some reason SweaveParseOptions was
> being called at all -- presumably it's looking at Rnw files, not
> knowing that they're really in knitr rather than Sweave format.
>
>   I'm sorry for the speculation and lack of reproducible examples
> here, but I thought it was worth commenting on.  If people are
> interested I can try to follow it up with a mini-package (one of the
> hard parts is that I can't actually reproduce the error myself -- I
> don't know if it's specific to Windows, or to not having knitr
> installed, or both ...)
>
>   Ben Bolker
>
> __
> 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

[Rd] should the text for RIGHT_ASSIGN be -> in getParseData()?

[Yihui Xie]

Hi,

The text column for '->' becomes '<-' in the data frame returned by
getParseData():

> getParseData(parse(text='1->x'))
  line1 col1 line2 col2 id parenttoken terminal text
7 11 14  7  0 exprFALSE
1 11 11  1  2NUM_CONST TRUE1
2 11 11  2  7 exprFALSE
3 12 13  3  7 RIGHT_ASSIGN TRUE   <-
4 14 14  4  6   SYMBOL TRUEx
6 14 14  6  7 exprFALSE

Is that expected?

> sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=C LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

Regards,
Yihui
--
Yihui Xie 
Phone: 206-667-4385 Web: http://yihui.name
Fred Hutchinson Cancer Research Center, Seattle

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

Re: [Rd] Patch proposal for R style consistency (concerning deparse.c)

[Yihui Xie]

I second the change of "} else {".

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Thu, Apr 18, 2013 at 11:16 AM, Paul Johnson  wrote:
> OK, I concede that.
>
> Now, how about "} else {"
>
> I will provide patch that does only that change.
> ?
>
> On Thu, Apr 18, 2013 at 3:05 AM, peter dalgaard  wrote:
>>
>> On Apr 18, 2013, at 05:39 , Paul Johnson wrote:
>>
>>> 2 & 3. I want to omit space after if and for.   Since if and for are
>>> functions in R, not keywords, I suggest that there should not be a
>>> space before the opening parentheses.
>>
>> Wrong. They are part of language constructs (and they _are_ keywords, not 
>> names, that's why ?for won't work). The function calls are `if`(fee, {foo}, 
>> {fie}) and something rebarbative for `for`().
>>
>> Besides, both constructs are harder to read without the spaces.
>>
>> --
>> 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
>>
>
>
>
> --
> Paul E. Johnson
> Professor, Political Science  Assoc. Director
> 1541 Lilac Lane, Room 504  Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org   http://quant.ku.edu

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

[Rd] localeToCharset() returns NA for the Hong Kong locale

[Yihui Xie]

Hi,

When Sys.getlocale("LC_CTYPE") returns 'Chinese (Traditional)_Hong
Kong S.A.R..950' to some Hong Kong Windows users, localeToCharset()
returns NA instead of CP950 due to:

> localeToCharset

if (.Platform$OS.type == "windows") {
x <- strsplit(locale, ".", fixed = TRUE)[[1L]]
if (length(x) != 2)
return(NA_character_)
switch(x[2L], `1252` = return("ISO8859-1"), `1257` =
return("ISO8859-13"))
return(paste0("CP", x[2L]))
}


Perhaps you should not assume length(x) == 2 when the locale string is
split by ., since in this case the dots in S.A.R. have a different
meaning (abbrev for Special Administrative Region). I would suggest
check if length(x) >= 2 and use the last element of x. Maybe you have
good reasons to require length(x) == 2.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

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

[Rd] savePlot() under Windows

[Yihui Xie]

Hi,

A Windows user asked me a question and I believe this is a bug of R
3.0.0 under Windows:

> plot(1:10)
> savePlot('test.wmf')
Error in .External(C_savePlot, device, filename, type, restoreConsole) :
  Incorrect number of arguments (4), expecting 3 for 'savePlot'

> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
[1] tools_3.0.0

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

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

Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC

[Yihui Xie]

I do not know much about S4, but I figured out one possible solution
on knitr's side, which I do not really understand. In short, your S4
methods need to be evaluated in globalenv(), but knitr uses the
parent.frame() by default, which is not the global environment when it
is called as the vignette builder.

Now I have forced the evaluation to be in the global environment, and
pushed the changes to the knitr development version on Github:
https://github.com/yihui/knitr

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Mon, Apr 1, 2013 at 7:37 PM, Henrik Bengtsson  wrote:
> Hi,
>
> things have indeed changed on how non-Sweave vignettes are built (this
> happened around R devel 2013-03-05 r62130).  However, it's not clear
> to me what changes would be behind your problems, if any.
>
> Build your vignette with the following buildVignette(), which emulates
> what R does when it builds vignettes (cf. tools::buildVignettes()).
> As you'll see, it reproduces your error:
>
> if (!exists("buildVignette", mode="function")) {
>   
> source("http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/R.rsp/R/buildVignette.R?root=r-dots";);
> }
>
> EXAMPLE (in a fresh R session):
>
> url <- 
> "http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/BayesFactorPCL/vignettes/manual.Rmd?root=bayesfactorpcl";
> if (!file.exists("manual.Rmd")) download.file(url, "manual.Rmd");
>
> output <- buildVignette("manual.Rmd", buildPkg="knitr");
> browseURL(output);
>
> bfr <- readLines(output);
> idxs <- grep("which.max(bf)", bfr, fixed=TRUE);
> idxs <- sort(sapply(idxs, FUN=function(idx) idx+(-5:5)));
> cat(sprintf("%03d: %s\n", idxs, bfr[idxs]));
>
>> cat(sprintf("%03d: %s", idxs, bfr[idxs]), sep="\n")
> 2517: 
> 2518:
> 2519: ## [1] TRUE
> 2520: 
> 2521:
> 2522: BayesFactor::which.max(bf)
> 2523: 
> 2524:
> 2525: ## complaints
> 2526: ##  1
> 2527: 
> 2531:
> 2532: ## critical + advance
> 2533: ## 21
> 2534: 
> 2535:
> 2536: which.max(bf)
> 2537: 
> 2538:
> 2539: ## Error: no method for coercing this S4 class to a vector
> 2540: 
> 2541:
>
> So, have a look at browseVignette() and how it calls the 'knitr' weave
> function.  That should help you narrow down what's going on.
>
>> sessionInfo()
> R version 3.0.0 RC (2013-03-31 r62463)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] tools stats graphics  grDevices utils datasets  methods
> [8] base
>
> other attached packages:
> [1] BayesFactor_0.9.3 markdown_0.5.4coda_0.16-1   lattice_0.20-15
> [5] knitr_1.1.7
>
> loaded via a namespace (and not attached):
> [1] digest_0.6.3 evaluate_0.4.3   formatR_0.7  grid_3.0.0
> [5] mvtnorm_0.9-9994 pbapply_1.0-5stringr_0.6.2
>
> Hope this helps
>
> /Henrik
>
> On Mon, Apr 1, 2013 at 4:52 PM, Richard D. Morey  wrote:
>> A new problem has cropped up with compiling vignettes for my package 
>> BayesFactor. I'm not sure when it started, but I can tell you it didn't 
>> occur on R 2.15.3, and it does on 3.0.0 RC (2013-03-31 r62463) (session info 
>> is at the bottom of this message).
>>
>> I have defined methods for which.min and which.max for a class (I've defined 
>> both S3 and S4 methods for the class "BFBayesFactor") in my package. I've 
>> exported the S4 class using exportMethods, and declared the S3 method with 
>> S3method. You can see the NAMESPACE file here:
>>
>> https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/NAMESPACE?view=markup&root=bayesfactorpcl
>>
>> and the methods here:
>>
>> https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/R/methods-BFBayesFactor.R?view=markup&root=bayesfactorpcl
>>
>> I have code in a vignette that calls the which.max method on a BFBayesFactor 
>> object. However, when that happens as the vignette is being compiled, I get 
>> an error:
>>
>> which.max(bf)
>> ## Error: no method for coercing this S4 class to a vector
>>
>>
>>
>> This also occurs with which.min, but oddly not any other method (including 
>> the is.na method, which is declared exactly the same way, as far as I

Re: [Rd] the case of building R snapshot without svn nor network connection.

[Yihui Xie]

"the only place for it is /dev/null" --> hi Achim, I bet this is a
nice fortune candidate :)

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sat, Mar 16, 2013 at 9:39 AM, Simon Urbanek
 wrote:
> On Mar 16, 2013, at 10:13 AM, Hin-Tak Leung wrote:
>
>> Network access is *not* a given, nor is the privilege of installing 
>> arbitrary "uncertified" and "non-essential" tools - whatever the meaning of 
>> "uncertified" and "non-essential" are, those being defined, as is "design 
>> goal", etc, by some small committee.
>>
>> It is a very common scenario, e.g. banks & telecom, some part of 
>> public/government service and health care. This does not seem to sink in 
>> without repeating.
>>
>
> Network access is not needed to build R - apparently that fact did not seem 
> to sink in, either. This entire thread is based on false assumptions and as 
> such the only place for it is /dev/null
>

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

[Rd] Why cannot `Rscript -e` accept an empty line?

[Yihui Xie]

See the example below (under Ubuntu):

$ Rscript -e '1' -e '2'
[1] 1
[1] 2
$ Rscript -e '1' -e '' -e '2'
ERROR: option '-e' requires an argument
$ uname -a
Linux xie 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

Similar problem under Windows:

Rscript -e "1" -e "" -e "2"
[1] 1
Error: object 'e' not found
Execution halted

I can certainly save the code in a script and run Rscript foo.R, but
I'm curious why Rscript stops when the -e argument is an empty string.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

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

Re: [Rd] enabling reproducible research & R package management & install.package.version & BiocLite

[Yihui Xie]

Just my 2 cents: it may not be a good idea to restrict software
versions to gain reproducibility. To me, this kind of reproducibility
is "dead" reproducibility (what if the old software has a fatal bug?
do we want to reproduce the same **wrong** results?). Software
packages are continuously evolving, and our research should be adapted
as well. How to achieve this? I think this paper by Robert Gentleman
and Duncan Temple Lang has given a nice answer:
http://biostats.bepress.com/bioconductor/paper2/

With R 3.0.0 coming, it will be easy to achieve what they have
outlined because R 3.0 allows custom vignette builders. Basically,
your research paper can be built with 'R CMD build' and checked with
'R CMD check' if you provide an appropriate builder. An R package has
the great potential of becoming the ideal tool for reproducible
research due to its wonderful infrastructure: functions, datasets,
examples, unit tests, vignettes, dependency structure, and so on. With
the help of version control, you can easily spot the changes after you
upgrade the packages. With an R package, you can automate a lot of
things, e.g. install.packages() will take care of dependencies and R
CMD build can rebuild your paper.

Just like Bioc has a devel version, you can continuously check your
results in a devel version, so that you know what is going to break if
you upgrade to new versions of other packages. Is developing a
research paper too different with developing a software package? (in
the context of computing) Probably not.

Long live the reproducible research!

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Mon, Mar 4, 2013 at 3:13 PM, Cook, Malcolm  wrote:
> Hi,
>
> In support of reproducible research at my Institute, I seek an approach to 
> re-creating the R environments in which an analysis has been conducted.
>
> By which I mean, the exact version of R and the exact version of all packages 
> used in a particular R session.
>
> I am seeking comments/criticism of this as a goal, and of the following 
> outline of an approach:
>
> === When all the steps to an workflow have been finalized ===
> * re-run the workflow from beginning to end
> * save the results of sessionInfo() into an RDS file named after the current 
> date and time.
>
> === Later, when desirous of exactly recreating this analysis ===
> * read the (old) sessionInfo() into an R session
> * exit with failure if the running version of R doesn't match
> * compare the old sessionInfo to the currently available installed libraries 
> (i.e. using packageVersion)
> * where there are discrepancies, install the required version of the package 
> (without dependencies) into new library (named after the old sessionInfo RDS 
> file)
>
> Then the analyst should be able to put the new library into the front of 
> .libPaths and run the analysis confident that the same version of the 
> packages.
>
> I have in that past used install-package-version.R  to revert to previous 
> versions of R packages successfully (https://gist.github.com/1503736).  And 
> there is a similar tool in Hadley Wickhams devtools.
>
> But, I don't know if I need something special for (BioConductor) packages 
> that have been installed using biocLite and seek advice here.
>
> I do understand that the R environment is not sufficient to guarantee 
> reproducibility.   Some of my colleagues have suggested saving a virtual 
> machine with all your software/library/data installed. So, I am also in 
> general interested in what other people are doing to this end.  But I am most 
> interested in:
>
> * is this a good idea
> * is there a worked out solution
> * does biocLite introduce special cases
> * where do the dragons lurk
>
> ... and the like
>
> Any tips?
>
> Thanks,
>
> ~ Malcolm Cook
> Stowers Institute / Computation Biology / Shilatifard Lab
>

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

Re: [Rd] CRAN task views: markdown? better .CSS?

[Yihui Xie]

See this page by Barry Rowlingson:
https://stat.ethz.ch/pipermail/r-devel/2012-February/063338.html

Given that CRAN maintainers do not even use JavaScript, I bet CSS does
not matter either; plain text is plain good.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Thu, Jan 31, 2013 at 8:50 AM, Michael Friendly  wrote:
> CRAN task views are useful, but they seem difficult to write and maintain
> because the XML format is rather
> limited (no sectioning) and the  must be maintained manually.
> They are also difficult to read because the generated html and .css used are
> extremely basic, giving an
> overly dense page.
>
> Are there any markdown-like tools for writing a CTV?  Is it possible to
> apply a custom .css to a CTV?
>
> -Michael
>
> --
> Michael Friendly Email: friendly AT yorku DOT ca
> Professor, Psychology Dept. & Chair, Quantitative Methods
> York University  Voice: 416 736-2100 x66249 Fax: 416 736-5814
> 4700 Keele StreetWeb:   http://www.datavis.ca
> Toronto, ONT  M3J 1P3 CANADA

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

Re: [Rd] Bug in R CMD check for \ in Rd?

[Yihui Xie]

Just a follow-up: I decided to avoid backslashes in function
arguments, so the problem is now gone for me. But I believe the
possible bug is still in R; if anyone wants to reproduce the problem,
please check out this commit:
https://github.com/yihui/knitr/tree/bf793ca6

https://github.com/yihui/knitr/blob/bf793ca67ac6b78a5b09ab8eb08976ec7667e6e2/man/knit_expand.Rd
https://github.com/yihui/knitr/blob/bf793ca67ac6b78a5b09ab8eb08976ec7667e6e2/R/template.R

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Thu, Jan 3, 2013 at 8:17 PM, Yihui Xie  wrote:
> Hi,
>
> I have a function knit_expand() and its source/Rd are below:
>
> https://github.com/yihui/knitr/blob/master/R/template.R#L43-L44
> https://github.com/yihui/knitr/blob/master/man/knit_expand.Rd
>
> When I run R CMD check on the package I get this warning (with both R
> 2.15.2 and R-devel):
>
> * checking for code/documentation mismatches ... WARNING
> Codoc mismatches from documentation object 'knit_expand':
> knit_expand
>   Code: function(file, ..., text = readLines(file, warn = FALSE), delim
>  = "\\{\\{((.|\n)+?)\\}\\}")
>   Docs: function(file, ..., text = readLines(file, warn = FALSE), delim
>  = "\{\{((.|\n)+?)\}\}")
>   Mismatches in argument default values:
> Name: 'delim' Code: "\\{\\{((.|\n)+?)\\}\\}" Docs: "\{\{((.|\n)+?)\}\}"
>
>
> I'm very confused by this warning, because in my Rd, I have this in
> the usage section:
>
> knit_expand(file, ..., text = readLines(file, warn = FALSE), delim =
> "{{((.|\\n)+?)}}")
>
> I do not understand why four backslashes became one in R CMD check. I
> read http://developer.r-project.org/parseRd.pdf again and it says {}
> in character strings do not need to be escaped, so the only character
> to escape in this case is the backslash. The text/html help page
> rendered from my Rd shows "\\{\\{((.|\n)+?)\\}\\}" correctly. So I'm
> wondering if this is a bug of R CMD check, or I misunderstood
> anything. Thanks!
>
> Regards,
> Yihui
> --
> Yihui Xie 
> Phone: 515-294-2465 Web: http://yihui.name
> Department of Statistics, Iowa State University
> 2215 Snedecor Hall, Ames, IA

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

[Rd] Bug in R CMD check for \ in Rd?

[Yihui Xie]

Hi,

I have a function knit_expand() and its source/Rd are below:

https://github.com/yihui/knitr/blob/master/R/template.R#L43-L44
https://github.com/yihui/knitr/blob/master/man/knit_expand.Rd

When I run R CMD check on the package I get this warning (with both R
2.15.2 and R-devel):

* checking for code/documentation mismatches ... WARNING
Codoc mismatches from documentation object 'knit_expand':
knit_expand
  Code: function(file, ..., text = readLines(file, warn = FALSE), delim
 = "\\{\\{((.|\n)+?)\\}\\}")
  Docs: function(file, ..., text = readLines(file, warn = FALSE), delim
 = "\{\{((.|\n)+?)\}\}")
  Mismatches in argument default values:
Name: 'delim' Code: "\\{\\{((.|\n)+?)\\}\\}" Docs: "\{\{((.|\n)+?)\}\}"


I'm very confused by this warning, because in my Rd, I have this in
the usage section:

knit_expand(file, ..., text = readLines(file, warn = FALSE), delim =
"{{((.|\\n)+?)}}")

I do not understand why four backslashes became one in R CMD check. I
read http://developer.r-project.org/parseRd.pdf again and it says {}
in character strings do not need to be escaped, so the only character
to escape in this case is the backslash. The text/html help page
rendered from my Rd shows "\\{\\{((.|\n)+?)\\}\\}" correctly. So I'm
wondering if this is a bug of R CMD check, or I misunderstood
anything. Thanks!

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

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

[Rd] customize building package vignettes

[Yihui Xie]

Hi,

I mentioned this at useR! 2012 but I guess the relevant R core members
were not there (presumably Fritz, Duncan and Brian), so I'm making
this wishlist again:

Currently package vignettes have to be processed through Sweave, which
is too restrictive since several add-on packages aiming to improve or
extend Sweave have appeared (e.g. cacheSweave, pgfSweave, R.rsp,
highlight, knitr, ...). The common hack that package authors use, as
far as I can see, is the Makefile. One example is at
https://github.com/yihui/knitr/blob/master/inst/doc/Makefile

Although this hack works well for some cases, it is potentially
problematic in two aspects:

1. The vignette has to be processed by Sweave anyway, and it is a
waste of time because it will be processed by another package later in
the Makefile;
2. The syntax of the vignette may not be compatible with Sweave, so
Sweave can run into errors (e.g. < 5) TRUE else
FALSE>>=); there is a darker hack for this but we really hate hacks;

Vignettes are extremely valuable resources for R packages, and I
really wish there could be a natural way for package developers to
compile vignettes using a customized routine. For example, introduce a
build.R under inst/doc or vignettes/ which takes care of building the
vignettes; if it does not exist, just call Sweave() as the default
approach.

Here is one discussion about a package on Bioconductor which should
strengthen my proposal:
http://grokbase.com/t/r/bioc-devel/129vxrxabm/to-use-knitr-how-to-write-the-right-makefile-for-bioconductor-devel-and-released-branch

There are further advantages if package authors are not restricted to
Sweave; the corrplot package is an example of building an HTML
vignette which could be easier for authors who are not familiar with
LaTeX and they can also distribute the vignette on the web easily.
See:

if (!require('corrplot')) install.packages('corrplot')
help(package = 'corrplot', help_type = 'html')

I have talked to some R core and Bioc core members offline, and this
seems to be a reasonable request. I will be grateful if this can be
considered and implemented in the future.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA

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