Re: [Bioc-devel] Build reports not updated

Hi Chen, You may check now. My package was built last night. Cheers, Monther On Fri, Jul 8, 2016 at 3:43 PM, Chen Hao wrote: > Dear Monther, > > There seems no building yesterday. Do you have any good news for the next > building? > I have a package(cytofkit)

Re: [Rd] Error building Tcl: R-patched_2016-07-05

On 07/07/2016 5:47 PM, Avraham Adler wrote: I am trying to build R under 64bit Windows7. I am using a fresh install of Rtools34 and R-patched_2016-07-05. I am getting the following error: C:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o tcltk.dll tmp.def init.o tcltk.o tcltk_win.o

[Rd] Error building Tcl: R-patched_2016-07-05

I am trying to build R under 64bit Windows7. I am using a fresh install of Rtools34 and R-patched_2016-07-05. I am getting the following error: C:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o tcltk.dll tmp.def init.o tcltk.o tcltk_win.o ../../../gnuwin32/dllversion.o

Re: [Bioc-devel] build error only occurs in window system

On 07/07/2016 04:29 PM, Hervé Pagès wrote: Hi Julie, On 07/07/2016 12:36 PM, Zhu, Lihua (Julie) wrote: Thanks Dan! I did came across a similar post a few years ago regarding its non-reproducibility http://r.789695.n4.nabble.com/quot-Failed-to-locate-the-texi2pdf-output-file-quot-td4664111.html

Re: [Bioc-devel] build error only occurs in window system

Herve, I strongly agree that the ultimate goal is to fix the issue. Thanks for the short term solution! Best, Julie Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged

Re: [Rd] String encoding problem

On 07/07/2016 12:51 PM, peter dalgaard wrote: > On 07 Jul 2016, at 18:15 , Hadley Wickham wrote: > > Right - I'm aware of that. But to me, it doesn't seem correct to > print a string that is not a valid R string. Why is an unknown > encoding printed like UTF-8? > It isn't

Re: [Bioc-devel] build error only occurs in window system

Don't bother. The issue is a long-standing one and very difficult to reproduce which is why it has not been fixed. It happens sporadically so the solution is to wait for the next day's build and it will clear itself up. Dan On July 7, 2016 11:05:22 AM PDT, "Ou, Jianhong"

Re: [Rd] Detecting user interrupts in R_tryEval

In R code tryCatch can detect the difference. Hit control-C (on Unixen) or Escape (on Windows) to interrupt the long-running for loop and see that the interrupt clause gets called: > z <- tryCatch(for(i in seq_len(1e8))log(exp(i/10)), error=function(e)e, interrupt=function(e)e) ^C> dput(z)

Re: [Bioc-devel] build error only occurs in window system

Hi Julie, You could try to install windows 10 in a virtualBox for debugging. virtualBox: https://www.virtualbox.org/wiki/Downloads Windows 10: https://www.microsoft.com/en-us/software-download/windows10/ Yours Sincerely, Jianhong Ou TEL: 508-856-5379 LRB 608 Bioinformatician of

[Rd] Detecting user interrupts in R_tryEval

Is there any way to distinguish between an error and a user interruption in R_tryEval? In both cases the ErrorOccurred argument is set to 1. For my application I need a different action in case of a SIGINT. >From the source code I infer that R_tryEval basically wraps eval in R_ToplevelExec, which

[Bioc-devel] build error only occurs in window system

Dan, I recently noticed that GUIDEseq page has a error build status at http://bioconductor.org/packages/release/bioc/html/GUIDEseq.html. Oddly, the error only occurs in the window server. Is this something related to the window server solvable by the core team, or should I change something to

Re: [Rd] String encoding problem

> On 07 Jul 2016, at 18:15 , Hadley Wickham wrote: > > Right - I'm aware of that. But to me, it doesn't seem correct to > print a string that is not a valid R string. Why is an unknown > encoding printed like UTF-8? > It isn't -- no UTF-8 would have the \xbf. I may be

Re: [Rd] String encoding problem

>>> I'm not sure what should happen here, but that's not a legal string in a >>> UTF-8 locale, so it's not too surprising that things go wonky. >> >> Here's bit more context on how I got that sequence of bytes: >> >> x <- "こんにちは" >> y <- iconv(x, to = "Shift-JIS") >> Encoding(y) >> y >> >> I did

Re: [Rd] String encoding problem

> On Jul 7, 2016, at 11:40 AM, Hadley Wickham wrote: > > On Thu, Jul 7, 2016 at 10:11 AM, Duncan Murdoch > wrote: >> On 07/07/2016 10:57 AM, Hadley Wickham wrote: >>> >>> If you print: >>> >>> "\xc9\x82\xbf" >>> >>> you get >>> >>>

Re: [Rd] String encoding problem

On Thu, Jul 7, 2016 at 10:11 AM, Duncan Murdoch wrote: > On 07/07/2016 10:57 AM, Hadley Wickham wrote: >> >> If you print: >> >> "\xc9\x82\xbf" >> >> you get >> >> "\u0242\xbf" >> >> But if you try and evaluate that string you get: >> >>> "\u0242\xbf" >> >> Error:

Re: [Rd] String encoding problem

On 07/07/2016 10:57 AM, Hadley Wickham wrote: If you print: "\xc9\x82\xbf" you get "\u0242\xbf" But if you try and evaluate that string you get: "\u0242\xbf" Error: mixing Unicode and octal/hex escapes in a string is not allowed (Probably will only happen on mac/linux with default

[Rd] String encoding problem

If you print: "\xc9\x82\xbf" you get "\u0242\xbf" But if you try and evaluate that string you get: > "\u0242\xbf" Error: mixing Unicode and octal/hex escapes in a string is not allowed (Probably will only happen on mac/linux with default utf-8 encoding) Hadley -- http://hadley.nz