[Rd] Running package tests and not stop on first fail

[Jan Gorecki]

Hello community/devs,
Is there an option to run package tests during R CMD check and not stop on
first error? I know that testing frameworks (testhat and others) can do
that but asking about just R and base packages. Currently when package
check runs test scripts in ./tests directory it will stop after first fail.
Do you think it could be optionally available to continue to run tests
after failures?
Regards,
Jan Gorecki

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Coverage test badge not updating

[Hervé Pagès]

Hi Leo,

I can confirm that while Bioc 3.4 was in devel, package coverage was
computed only for the devel version of packages. When we released
BioC 3.4, I moved the compute_coverage script that used to run on
zin1 (which used to be the central build node for BioC 3.4 for months)
to malbec2, which is the central build node for BioC 3.5.

So yes, package coverage is still only computed for devel packages
at the moment. We'll see if we can restore package coverage for
release. If, for whatever reason, this is not possible or is too
complicated, we'll remove the badges from the release landing pages.

Thanks for the reminder!

Cheers,
H.

On 11/01/2016 12:18 PM, Leonardo Collado Torres wrote:

Hi,

I know that there are several old threads about the coverage badges
including this thread. Basically, while Bioc 3.4 was in devel, the
coverage badges didn't work for Bioc release (3.3). However, now that
3.4 has been released, the badges for Bioc-release (3.4) are still not
working and they only work for Bioc-devel (3.5).

In one of the threads, Dan mentioned that something at codecov had
changed and that he was going to ask for advice on how to proceed. I'm
just curious if there are any updates on this issue. If it's only
possible to have the coverage badges work for one branch, then it
might be best to leave them in Bioc-devel (given Jim's arguments
earlier) and remove them from Bioc-release.

Best,
Leo

On Mon, Nov 23, 2015 at 4:25 PM, Leonardo Collado Torres
 wrote:


Thank you for fixing this Jim! I noticed it working now on devel.
However, I believe that is still not working for the release branch.

Cheers,
Leo

On Fri, Nov 20, 2015 at 3:37 PM, Jim Hester  wrote:

The coverage tests were inadvertently not running, but they are now
re-enabled.

Please let us know if you notice any other problems

Jim

On Tue, Nov 17, 2015 at 12:16 PM, Leonardo Collado Torres 
wrote:


Hi,

In my packages I enabled testing (via testthat) a few weeks ago. I did
so as can be seen in

https://github.com/leekgroup/derfinderHelper/commit/26d9d5543d9082f85bbb2d0ae9f02c5c309b9a48
for the changes to tests/test-all.R You can see that the tests are
actually being run at

http://bioconductor.org/checkResults/devel/bioc-LATEST/derfinderHelper/zin2-checksrc.html
Specifically at the lines:

* checking tests ...
  Running ‘test-all.R’ [3s/13s]
 [3s/14s] OK

I'm wondering if the coverage tests are only run at a less frequent
pace (say once per month) or if my tests/test-all.R file is still
posing problems to covr.

Thanks,
Leo

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel





___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] as.formula("x") error on C stack limit

[András Tajti]

Thank you for the exhausting answer.

Is it possible to add a note to the help page regarding the conclusion (or
even the edge cases)?

is it possible to add any validation for x in formula.character?

On 1 November 2016 at 21:48, William Dunlap  wrote:

> Another example uses formula.character's other arguments:
> > as.formula("env")
> Error: object of type 'special' is not subsettable
> > as.formula("...")
> Error in eval(expr, envir, enclos) : '...' used in an incorrect context
>
>
> It may happen for the same reason that the following does not give an
> error:
> > y <- "response ~ pred1 + pred2"
> > as.formula("y")
> response ~ pred1 + pred2
>
> and that the followings give a somewhat surprising result
>
> > f <- function(x) { y <- "foo ~ bar" ; as.formula(x) }
> > f("y")
> response ~ pred1 + pred2
> 
>
> The character method for formula works well if its 'x' argument looks like
> a formula, but it doesn't act consistently otherwise.
>
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Tue, Nov 1, 2016 at 12:54 PM, András Tajti  wrote:
>
>> Dear all,
>> I tried to run as.formula("x") and got an error message "Error: C stack
>> usage  7971120 is too close to the limit" whether x exists or not. This is
>> not the case in as.formula("y"), where "object 'y'  not found" is the
>> error
>> message if y not exists, or "invalid formula" error or a formula depending
>> on y. Can anyone confirm this is not my special problem, or if it is, why
>> it can happen?
>>
>> Thank you:
>> András
>>
>> Below the output of sessionInfo():
>>
>> R version 3.3.1 (2016-06-21)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 14.04.5 LTS
>>
>> locale:
>>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>>  [3] LC_TIME=hu_HU.UTF-8LC_COLLATE=en_US.UTF-8
>>  [5] LC_MONETARY=hu_HU.UTF-8LC_MESSAGES=en_US.UTF-8
>>  [7] LC_PAPER=hu_HU.UTF-8   LC_NAME=C
>>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=hu_HU.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> [[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] as.formula("x") error on C stack limit

[William Dunlap via R-devel]

Another example uses formula.character's other arguments:
> as.formula("env")
Error: object of type 'special' is not subsettable
> as.formula("...")
Error in eval(expr, envir, enclos) : '...' used in an incorrect context


It may happen for the same reason that the following does not give an error:
> y <- "response ~ pred1 + pred2"
> as.formula("y")
response ~ pred1 + pred2

and that the followings give a somewhat surprising result

> f <- function(x) { y <- "foo ~ bar" ; as.formula(x) }
> f("y")
response ~ pred1 + pred2


The character method for formula works well if its 'x' argument looks like
a formula, but it doesn't act consistently otherwise.



Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Tue, Nov 1, 2016 at 12:54 PM, András Tajti  wrote:

> Dear all,
> I tried to run as.formula("x") and got an error message "Error: C stack
> usage  7971120 is too close to the limit" whether x exists or not. This is
> not the case in as.formula("y"), where "object 'y'  not found" is the error
> message if y not exists, or "invalid formula" error or a formula depending
> on y. Can anyone confirm this is not my special problem, or if it is, why
> it can happen?
>
> Thank you:
> András
>
> Below the output of sessionInfo():
>
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.5 LTS
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=hu_HU.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=hu_HU.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=hu_HU.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=hu_HU.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> [[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] as.formula("x") error on C stack limit

[András Tajti]

Dear all,
I tried to run as.formula("x") and got an error message "Error: C stack
usage  7971120 is too close to the limit" whether x exists or not. This is
not the case in as.formula("y"), where "object 'y'  not found" is the error
message if y not exists, or "invalid formula" error or a formula depending
on y. Can anyone confirm this is not my special problem, or if it is, why
it can happen?

Thank you:
András

Below the output of sessionInfo():

R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

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

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

[[alternative HTML version deleted]]

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

[R-pkg-devel] Package submissions via ftp will no longer be accepted by CRAN

[Duncan Murdoch]

A notice to package developers:

For a long time CRAN has encouraged package maintainers to submit 
packages via the web submission page linked from




This makes handling submissions substantially easier for us, and we have 
decided that it will be a requirement for submission from now on.


Documentation updates will be showing up as we find them.

Duncan Murdoch

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

Re: [Bioc-devel] Coverage test badge not updating

[Leonardo Collado Torres]

Hi,

I know that there are several old threads about the coverage badges
including this thread. Basically, while Bioc 3.4 was in devel, the
coverage badges didn't work for Bioc release (3.3). However, now that
3.4 has been released, the badges for Bioc-release (3.4) are still not
working and they only work for Bioc-devel (3.5).

In one of the threads, Dan mentioned that something at codecov had
changed and that he was going to ask for advice on how to proceed. I'm
just curious if there are any updates on this issue. If it's only
possible to have the coverage badges work for one branch, then it
might be best to leave them in Bioc-devel (given Jim's arguments
earlier) and remove them from Bioc-release.

Best,
Leo

On Mon, Nov 23, 2015 at 4:25 PM, Leonardo Collado Torres
 wrote:
>
> Thank you for fixing this Jim! I noticed it working now on devel.
> However, I believe that is still not working for the release branch.
>
> Cheers,
> Leo
>
> On Fri, Nov 20, 2015 at 3:37 PM, Jim Hester  wrote:
> > The coverage tests were inadvertently not running, but they are now
> > re-enabled.
> >
> > Please let us know if you notice any other problems
> >
> > Jim
> >
> > On Tue, Nov 17, 2015 at 12:16 PM, Leonardo Collado Torres 
> > wrote:
> >>
> >> Hi,
> >>
> >> In my packages I enabled testing (via testthat) a few weeks ago. I did
> >> so as can be seen in
> >>
> >> https://github.com/leekgroup/derfinderHelper/commit/26d9d5543d9082f85bbb2d0ae9f02c5c309b9a48
> >> for the changes to tests/test-all.R You can see that the tests are
> >> actually being run at
> >>
> >> http://bioconductor.org/checkResults/devel/bioc-LATEST/derfinderHelper/zin2-checksrc.html
> >> Specifically at the lines:
> >>
> >> * checking tests ...
> >>   Running ‘test-all.R’ [3s/13s]
> >>  [3s/14s] OK
> >>
> >> I'm wondering if the coverage tests are only run at a less frequent
> >> pace (say once per month) or if my tests/test-all.R file is still
> >> posing problems to covr.
> >>
> >> Thanks,
> >> Leo
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] building binary gives error when trying to load

[Duncan Murdoch]

On 01/11/2016 1:10 PM, Henric Winell wrote:

On 2016-11-01 17:01, Uwe Ligges wrote:

> On 01.11.2016 15:56, Duncan Murdoch wrote:
>> On 01/11/2016 9:49 AM, Rampal Etienne wrote:
>>> Dear all,
>>>
>>> When I try to build a Windows binary in RStudio using R-devel,
>>> everything goes well until the packages is tested whether it can be
>>> loaded. I then get the error:
>>>
>>> ** testing if installed package can be loaded *** arch - i386 Error:
>>> '\U' used without hex digits in character string starting "'C:\U"
>>> Execution halted *** arch - x64 Error: '\U' used without hex digits in
>>> character string starting "'C:\U" Execution halted ERROR: loading failed
>>> for 'i386', 'x64' * removing
>>> 
'C:\Users\rampa\AppData\Local\Temp\Rtmp0o1Fm1\temp_libpath1cd445c31688/SADISA'
>>>
>>>
>>> Error: Command failed (1) Execution halted Exited with status 1.
>>
>> That looks like a bug.
>
>
> Indeed, it is also fairly new, as I typically do manual stuff that way
> and it hit me 5 minuites ago. Sorry for not having tested it as I did
> not believe there was a newly introduced bug.
>
> Uwe

I reported this issue to R-devel about ten days ago.

https://stat.ethz.ch/pipermail/r-devel/2016-October/073286.html


Yes, it's been there for a few weeks.  I suspect Uwe has a more complete 
set of environment variables than most people, and some of those could 
have masked the error.


As for me, I rarely develop packages on Windows any more.

Now that Microsoft is pushing their R products so much, you'd think they 
could contribute some time to supporting their platform.


Duncan Murdoch



Henric Winell



>

>
>
>   It's in R, not RStudio.  To reproduce, start
>> cmd.exe, and switch to a directory containing a source tarball or a
>> source directory, and run
>>
>> R CMD INSTALL --build 
>>
>> For instance, when I do that with the tables package, I get
>>
>> D:\svn\MyR>R CMD INSTALL --build tables
>> * installing to library 'f:\cygwin\home\murdoch\R\win-library\3.4'
>> * installing *source* package 'tables' ...
>> ** R
>> ** preparing package for lazy loading
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** installing vignettes
>> ** testing if installed package can be loaded
>> Error: '\c' is an unrecognized escape in character string starting
>> "'f:\c"
>> Execution halted
>> ERROR: loading failed
>> * removing 'f:\cygwin\home\murdoch\R\win-library\3.4/tables'
>> * restoring previous 'f:\cygwin\home\murdoch\R\win-library\3.4/tables'
>>
>> It appears that the script is building paths including unescaped
>> backslashes when it constructs the library path.  You can probably work
>> around it by specifying the library path explicitly.  Since you were
>> installing into a temporary library, that's a little tricky, but for
>> most people it should be easy.
>>
>> I'll see if I can track it down and fix it.
>>
>> Duncan Murdoch
>>
>>>
>>>
>>> I have updated RStudio, Rtools and Rdevel,and the problem persists. Does
>>> anyone have a clue how to solve this?
>>>
>>> Before I updated to the newest Rdevel, everything worked fine.
>>>
>>> Kind regards, Rampal Etienne
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>



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

Re: [Rd] BUG?: On Linux setTimeLimit() fails to propagate timeout error when it occurs (works on Windows)

[Henrik Bengtsson]

On Mon, Oct 31, 2016 at 9:36 AM,   wrote:
> On Mon, 31 Oct 2016, Henrik Bengtsson wrote:
>
>> Thank you for looking into this Luke.
>>
>> On Thu, Oct 27, 2016 at 9:26 AM,   wrote:
>>>
>>> On unix, unless event polling is enabled Sys.sleep just waits in a
>>> select() call (with a SIGINT handler in place) so the elapsed time
>>> isn't checked until after the select call is complete. Rstudio uses
>>> event polling, and in particular sets R_wait_usec to 1, which
>>> means event and interrupt checks happen during a Sys.seep call.  The R
>>> GUI on macOS doesn't seem to do this (but my lldb skills aren't up to
>>> checking). Now that we have this elapsed time limit mechanism it might
>>> be a good idea to set the default for R_wait_usec to something
>>> reasonable on unix in general. 10 might be a good value.
>>>
>>
>>> A more worrying thing I noticed while looking at this is that blocking
>>> reads on fifos and pipes and probably sockets are not interruptable --
>>> that should probably be looked into.
>
>
> I'll address the sleep issue sometime soon but I won't be able to look
> into the blocking read issue for many months. SOmeone else might have
> a chance to look earlier.

Thanks.

So, if I understand it correctly, my example showing that
setTimeLimit() doesn't work properly on Linux was unfortunately
misleading, mainly due to me choosing Sys.sleep() and it does indeed
work in most cases (except connections).  For example, this works

slowfcn <- function(time) { t0 <- Sys.time(); while(Sys.time() - t0 <
time) Sys.sleep(0.1); TRUE }
setTimeLimit(elapsed = 1.0)
system.time(slowfcn(3))
## Error in Sys.sleep(0.1) : reached elapsed time limit
## Timing stopped at: 0.004 0 1.008

> But for the situation you describe below using setTimeLimit doesn't
> seem like the right approach. The parallel code is not written for
> situations that need this kind of fault tolerance; it is not robust to
> user interrupts and would not be to timer interrupts either. If you
> are concerned that some potential workers might not be available then
> you would be better checking that with a ping or simple ssh commend
> first before starting a cluster on the available nodes.

Yes, true. I didn't want to sidetrack the discussion too much, but
I've started to make some standalone improvements based on
parallel:::newPSOCKnode() & parallel:::.slaveRSOCK(), e.g. more
control options for launching remote workers, say, over SSH with
reverse tunneling (no need for port forwarding) and then running
Rscript within a Docker container, e.g.

https://github.com/HenrikBengtsson/future/blob/develop/R/makeClusterPSOCK.R
https://github.com/HenrikBengtsson/future/blob/develop/incl/makeClusterPSOCK.R

This part is fully backward compatible with makePSOCKcluster() and
could be eventually be implemented in parallel itself.  The next level
up could be to make the worker loop to handle connection-setup
timeouts and similar.

By now I'm fairly ok with testing and validating remote SSH access
etc, but I think it's possible to make exception handling a little bit
more automatic and informative, particularly the part detecting when
the connection and worker setup actually never happens.  For a
newcomer, it can be quite a challenge to troubleshoot why the setup of
remote workers doesn't work.

Thanks,

Henrik

>
> Best,
>
> luke
>
>
>>
>> This is actually related to the use case where I want to use
>> setTimeLimit().  When using parallel:::newPSOCKnode(), there's a
>> 30-day timeout associated with the socket connection.  Now, this long
>> timeout is needed in order for long-running tasks to not to timeout
>> the master-worker connection.   However, when it comes to the actual
>> setup of the connection, then it would be able to detect connection
>> issues earlier than that.  For example, if the socket connection
>> cannot be established within 60 seconds, then it is very likely that
>> the worker machine couldn't be reached, especially for connecting to
>> remote machines over SSH.
>>
>> The current code of parallel:::newPSOCKnode() basically does:
>>
>> system("ssh remote.server.org Rscript -e > back>", wait = FALSE)
>> con <- socketConnection("localhost", port = 11000, server = TRUE,
>> blocking = TRUE, open = "a+b", timeout = 30*24*60*60)
>>
>> If the remote SSH system call fails to reach or set up the worker, the
>> following call to socketConnection() will sit there and wait for 30
>> days.  Ideally one could solve this as:
>>
>> system("ssh remote.server.org Rscript -e > back>", wait = FALSE)
>> setTimeLimit(elapsed=60)
>> con <- socketConnection("localhost", port = 11000, server = TRUE,
>> blocking = TRUE, open = "a+b", timeout = 30*24*60*60)
>>
>> Thanks,
>>
>> Henrik
>>
>>>
>>> Best,
>>>
>>> luke
>>>
>>>
>>> On Wed, 26 Oct 2016, peter dalgaard wrote:
>>>
 Spencer also had tools and rsconnect loaded (via a namespace) but it
 doesn't seem to make a difference for me if I load them. It also 

Re: [R-pkg-devel] building binary gives error when trying to load

[Uwe Ligges]

On 01.11.2016 15:56, Duncan Murdoch wrote:

On 01/11/2016 9:49 AM, Rampal Etienne wrote:

Dear all,

When I try to build a Windows binary in RStudio using R-devel,
everything goes well until the packages is tested whether it can be
loaded. I then get the error:

** testing if installed package can be loaded *** arch - i386 Error:
'\U' used without hex digits in character string starting "'C:\U"
Execution halted *** arch - x64 Error: '\U' used without hex digits in
character string starting "'C:\U" Execution halted ERROR: loading failed
for 'i386', 'x64' * removing
'C:\Users\rampa\AppData\Local\Temp\Rtmp0o1Fm1\temp_libpath1cd445c31688/SADISA'

Error: Command failed (1) Execution halted Exited with status 1.


That looks like a bug.



Indeed, it is also fairly new, as I typically do manual stuff that way 
and it hit me 5 minuites ago. Sorry for not having tested it as I did 
not believe there was a newly introduced bug.


Uwe



  It's in R, not RStudio.  To reproduce, start

cmd.exe, and switch to a directory containing a source tarball or a
source directory, and run

R CMD INSTALL --build 

For instance, when I do that with the tables package, I get

D:\svn\MyR>R CMD INSTALL --build tables
* installing to library 'f:\cygwin\home\murdoch\R\win-library\3.4'
* installing *source* package 'tables' ...
** R
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error: '\c' is an unrecognized escape in character string starting "'f:\c"
Execution halted
ERROR: loading failed
* removing 'f:\cygwin\home\murdoch\R\win-library\3.4/tables'
* restoring previous 'f:\cygwin\home\murdoch\R\win-library\3.4/tables'

It appears that the script is building paths including unescaped
backslashes when it constructs the library path.  You can probably work
around it by specifying the library path explicitly.  Since you were
installing into a temporary library, that's a little tricky, but for
most people it should be easy.

I'll see if I can track it down and fix it.

Duncan Murdoch




I have updated RStudio, Rtools and Rdevel,and the problem persists. Does
anyone have a clue how to solve this?

Before I updated to the newest Rdevel, everything worked fine.

Kind regards, Rampal Etienne

[[alternative HTML version deleted]]

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


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


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

Re: [R-pkg-devel] building binary gives error when trying to load

[Uwe Ligges]

Use forward slashes in file specification such as c:/Users/rampa/

Best,
Uwe Ligges



On 01.11.2016 14:49, Rampal Etienne wrote:

Dear all,

When I try to build a Windows binary in RStudio using R-devel,
everything goes well until the packages is tested whether it can be
loaded. I then get the error:

** testing if installed package can be loaded *** arch - i386 Error:
'\U' used without hex digits in character string starting "'C:\U"
Execution halted *** arch - x64 Error: '\U' used without hex digits in
character string starting "'C:\U" Execution halted ERROR: loading failed
for 'i386', 'x64' * removing
'C:\Users\rampa\AppData\Local\Temp\Rtmp0o1Fm1\temp_libpath1cd445c31688/SADISA'
Error: Command failed (1) Execution halted Exited with status 1.


I have updated RStudio, Rtools and Rdevel,and the problem persists. Does
anyone have a clue how to solve this?

Before I updated to the newest Rdevel, everything worked fine.

Kind regards, Rampal Etienne

[[alternative HTML version deleted]]

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



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

[R-pkg-devel] building binary gives error when trying to load

[Rampal Etienne]

Dear all,

When I try to build a Windows binary in RStudio using R-devel, 
everything goes well until the packages is tested whether it can be 
loaded. I then get the error:

** testing if installed package can be loaded *** arch - i386 Error: 
'\U' used without hex digits in character string starting "'C:\U" 
Execution halted *** arch - x64 Error: '\U' used without hex digits in 
character string starting "'C:\U" Execution halted ERROR: loading failed 
for 'i386', 'x64' * removing 
'C:\Users\rampa\AppData\Local\Temp\Rtmp0o1Fm1\temp_libpath1cd445c31688/SADISA' 
Error: Command failed (1) Execution halted Exited with status 1.


I have updated RStudio, Rtools and Rdevel,and the problem persists. Does 
anyone have a clue how to solve this?

Before I updated to the newest Rdevel, everything worked fine.

Kind regards, Rampal Etienne

[[alternative HTML version deleted]]

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

Re: [Rd] Support for signing R packages with GPG

[Jeroen Ooms]

On Tue, Oct 25, 2016 at 7:22 PM, Martyn Plummer  wrote:
> Thanks Jeroen. The R Foundation has recently formed a working group to
> look into package authentication. There are basically two models. One
> is the GPG based model you describe; the other is to use X.509 as
> implemented in the PKI package. It's not yet clear which way to go but
> we are thinking about it.

I look forward to hearing what the working group comes up with. I
suppose if you go with x509, CRAN is going to perform CA duties?

Let me know if I can help with implementation, either via gpg or x509.
I am actively developing the openssl package which includes many more
x509 utilities, supporting all common key types (dsa, rsa, ec),
certificate bundles, ssl, etc. The main difference with PKI is that
openssl uses the native pem/der parsers from libssl which are more
robust and also recognize the less common formats, so that we don't
have to deal with parsing/decoding ASN.1 in R.

I will be happy to adapt/extend it further to fit the needs of the
workgroup and help this move forward.

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

Re: [Bioc-devel] FlipFlop Ignores Read Strand and Requires Antiquated File Formats

[Wolfgang Huber]

Dear Dario

These all look like legitimate suggestions, and probably the package author has 
something to say on their substance.

But independent of the specifics here, I think we should also keep in mind that 
the motivations for package submission vary across the project.
Some contributors really take it on themselves to continuously develop and 
extend a solution for a particular field of science or technology.
This is great, in particular for users.

Others provide a ‘snapshot’ of their work at a particular point in time (e.g. 
end of PhD thesis) and make their research reproducible, so that others can 
build on top of it. This is the same as with research papers, which are also 
rarely supposed to be the “final word” on something but an important advance.
I think this is also great, for the scientific record, and for other method 
developers who can start from such a snapshot (if not literally then at least 
conceptually) and move on to do even greater things.

Best wishes
Wolfgang


> On Nov 1, 2016, at 6:00 GMT+1, Dario Strbenac  
> wrote:
> 
> Hello,
> 
> The package FlipFlop is made for isoform quantitiation. Why are there no 
> options to specify the RNA-seq read strand ? Otherwise, the method produces 
> incorrect counts where overlapping genes on both strands are being 
> transcribed. Also, the software requires a SAM file as input. This is 
> inefficient, since most mapping results are stored as BAM files. It would be 
> better if FlipFlop made more use of the import and export functions available 
> in Rsamtools. Also, requiring the gene database to be in BED12 format creates 
> more unnecessary work for the user. ENSEMBL and GENCODE both provide GTF and 
> GFF3 files, which can easily be imported into R with functions provided by 
> rtracklayer.
> 
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel


Wolfgang Huber
Principal Investigator, EMBL Senior Scientist
Genome Biology Unit
European Molecular Biology Laboratory (EMBL)
Heidelberg, Germany

wolfgang.hu...@embl.de
http://www.huber.embl.de

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] FlipFlop Ignores Read Strand and Requires Antiquated File Formats

[Dario Strbenac]

Hello,

The package FlipFlop is made for isoform quantitiation. Why are there no 
options to specify the RNA-seq read strand ? Otherwise, the method produces 
incorrect counts where overlapping genes on both strands are being transcribed. 
Also, the software requires a SAM file as input. This is inefficient, since 
most mapping results are stored as BAM files. It would be better if FlipFlop 
made more use of the import and export functions available in Rsamtools. Also, 
requiring the gene database to be in BED12 format creates more unnecessary work 
for the user. ENSEMBL and GENCODE both provide GTF and GFF3 files, which can 
easily be imported into R with functions provided by rtracklayer.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel