Re: [Bioc-devel] Package not being built on Windows or Mac

2017-03-20 Thread Dan Tenenbaum 
As I recall, there were issues building RCytoscape (and packages that depend on 
it) on Mac and Windows. Mostly because this requires a running instance of 
Cytoscape for each platform (and double that for release + devel). That used 
too much infrastructure so we disabled building on those platforms. However, 
since RCytoscape contains no native (C/C++/Fortran) code, it will still be 
available on all platforms and should install just fine.

As long as the same is true of categoryCompare then Mac/Windows users should be 
able to use it.

Dan


- Original Message -
> From: "James W. MacDonald" 
> To: "Robert M. Flight" 
> Cc: "bioc-devel" 
> Sent: Monday, March 20, 2017 2:22:36 PM
> Subject: Re: [Bioc-devel] Package not being built on Windows or Mac

> It's probably because you depend on RCytoscape, which isn't supported on
> Windows or MacOS. And maybe this has something to do with XMLRPC?
> 
> Jim
> 
> 
> 
> On Mon, Mar 20, 2017 at 4:59 PM, Robert M. Flight 
> wrote:
> 
>> As per the exhortation to check the build status on Devel prior to next
>> version of Bioconductor release, I just noticed that my package
>> categoryCompare has a "not supported" on Windows and Mac.
>>
>> Looking at release history, this seems to  I have changed at Bioc v 3.4,
>> and I'm curious why that would be the case.
>>
>> Regards,
>>
>> Robert
>>
>> Robert M Flight, PhD
>> Bioinformatics Research Associate
>> Puller of Rabbits from Hats
>> Resource Center for Stable Isotope Resolved Metabolomics
>> Manager, Systems Biology and Omics Integration Journal Club
>> Markey Cancer Center
>> CC434 Roach Building
>> University of Kentucky
>> Lexington, KY
>>
>> Twitter: @rmflight
>> Web: rmflight.github.io
>> ORCID:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__orcid.org_-2D0001-2D8141-2D7788=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=n-q_ynuSgrWSRqpLP4_jtAcjUUkBkQS47cGcISvMTH8=
>> EM rfligh...@gmail.com
>> PH 502-509-1827
>>
>> To call in the statistician after the experiment is done may be no more
>> than asking him to perform a post-mortem examination: he may be able to say
>> what the experiment died of. - Ronald Fisher
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=s4b92CENsDvGb5LJKA-xyg2pTKm6kJHUNfyOrk_ySY4=
>>
> 
> 
> 
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
> 
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=s4b92CENsDvGb5LJKA-xyg2pTKm6kJHUNfyOrk_ySY4=

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

Re: [R-pkg-devel] How do you discover and learn about R packages?

2017-03-20 Thread Julia Silge 
Yes, great input! I appreciate Dirk also bringing up CRANberries earlier;
it is such a valuable resource. I know that users are glad to access it via
Twitter and its separate website.

Thanks so much,
Julia


On Mon, Mar 20, 2017 at 3:27 PM Mark van der Loo 
wrote:

> Julia,
>
> Just took the poll.
>
> I think cranberries would deserve mention there as well. It is the only
> continuous feed that reports in new pkgs and updates (that I know of).
>
> Best,
> Mark
>
> On Mon, Mar 20, 2017, 14:57 Julia Silge  wrote:
>
> I am contributing to a session at userR 2017 this coming July that will
> focus on discovering and learning about R packages. This is an increasingly
> important issue for R users as we all decide which of the 10,000+ packages
> to invest time in understanding and then use in our work.
>
> To prepare for this session and gain some understanding, I am running an
> online survey about how R users currently discover and learn about R
> packages:
> http://doo.vote/a87ff60
>
> The question has one multiple select question about how you currently
> discover and learn about R packages. If you have other ways that you don’t
> feel were fairly covered in the survey options, feel free to reply to me or
> leave a comment here on my blog:
> http://juliasilge.com/blog/Package-Search/
>
> Thanks,
> Julia
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How do you discover and learn about R packages?

2017-03-20 Thread Mark van der Loo 
Julia,

Just took the poll.

I think cranberries would deserve mention there as well. It is the only
continuous feed that reports in new pkgs and updates (that I know of).

Best,
Mark

On Mon, Mar 20, 2017, 14:57 Julia Silge  wrote:

> I am contributing to a session at userR 2017 this coming July that will
> focus on discovering and learning about R packages. This is an increasingly
> important issue for R users as we all decide which of the 10,000+ packages
> to invest time in understanding and then use in our work.
>
> To prepare for this session and gain some understanding, I am running an
> online survey about how R users currently discover and learn about R
> packages:
> http://doo.vote/a87ff60
>
> The question has one multiple select question about how you currently
> discover and learn about R packages. If you have other ways that you don’t
> feel were fairly covered in the survey options, feel free to reply to me or
> leave a comment here on my blog:
> http://juliasilge.com/blog/Package-Search/
>
> Thanks,
> Julia
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Package not being built on Windows or Mac

2017-03-20 Thread James W. MacDonald 
It's probably because you depend on RCytoscape, which isn't supported on
Windows or MacOS. And maybe this has something to do with XMLRPC?

Jim



On Mon, Mar 20, 2017 at 4:59 PM, Robert M. Flight 
wrote:

> As per the exhortation to check the build status on Devel prior to next
> version of Bioconductor release, I just noticed that my package
> categoryCompare has a "not supported" on Windows and Mac.
>
> Looking at release history, this seems to  I have changed at Bioc v 3.4,
> and I'm curious why that would be the case.
>
> Regards,
>
> Robert
>
> Robert M Flight, PhD
> Bioinformatics Research Associate
> Puller of Rabbits from Hats
> Resource Center for Stable Isotope Resolved Metabolomics
> Manager, Systems Biology and Omics Integration Journal Club
> Markey Cancer Center
> CC434 Roach Building
> University of Kentucky
> Lexington, KY
>
> Twitter: @rmflight
> Web: rmflight.github.io
> ORCID: http://orcid.org/-0001-8141-7788
> EM rfligh...@gmail.com
> PH 502-509-1827
>
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. - Ronald Fisher
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

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

[Bioc-devel] Package not being built on Windows or Mac

2017-03-20 Thread Robert M. Flight 
As per the exhortation to check the build status on Devel prior to next
version of Bioconductor release, I just noticed that my package
categoryCompare has a "not supported" on Windows and Mac.

Looking at release history, this seems to  I have changed at Bioc v 3.4,
and I'm curious why that would be the case.

Regards,

Robert

Robert M Flight, PhD
Bioinformatics Research Associate
Puller of Rabbits from Hats
Resource Center for Stable Isotope Resolved Metabolomics
Manager, Systems Biology and Omics Integration Journal Club
Markey Cancer Center
CC434 Roach Building
University of Kentucky
Lexington, KY

Twitter: @rmflight
Web: rmflight.github.io
ORCID: http://orcid.org/-0001-8141-7788
EM rfligh...@gmail.com
PH 502-509-1827

To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. - Ronald Fisher

[[alternative HTML version deleted]]

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

[Bioc-devel] tximport fails to build on Windows

2017-03-20 Thread Michael Love 
Anyone have any ideas for how to debug this?

I get an error from the tximport vignette on tokay2, but I can't
figure out what could be the issue:

...
1 Quitting from lines 185-189 (tximport.Rmd)
Error: processing vignette 'tximport.Rmd' failed with diagnostics:
cannot open the connection
Execution halted

http://master.bioconductor.org/checkResults/devel/bioc-LATEST/tximport/tokay2-buildsrc.html

Those lines look innocuous to me, and work fine on Linux and Mac:

184 ```{r}
185 files <- file.path(dir,"sailfish", samples$run, "quant.sf")
186 names(files) <- paste0("sample",1:6)
187 txi.sailfish <- tximport(files, type="sailfish", tx2gene=tx2gene)
188 head(txi.sailfish$counts)
189 ```

I tried bumping the version and I still get the error from tokay2.

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

[Bioc-devel] Bioconductor 3.5 release

2017-03-20 Thread Obenchain, Valerie 
Hi all,

The release of Bioconductor 3.5 will be Tuesday, April 25. Please see
the schedule for details:

  http://www.bioconductor.org/developers/release-schedule/

Over the next month we'll announce the key deadlines on bioc-devel. Lori
sent the first one last week and it's important for anyone planning to
submit a new package:

  https://stat.ethz.ch/pipermail/bioc-devel/2017-March/010594.html

As you know, part of preparing for the release is cleaning up the
software and experimental data build reports. It would be greatly
appreciated if you could proactively look at your packages and help us
get them "in the green" with a clean build and check.

  http://www.bioconductor.org/checkResults/


Thanks.

Valerie




This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Perl version issue with building Rhtslib

2017-03-20 Thread Martin Morgan 
Hi Dinakar -- your patch didn't make it through the mailing list; can 
you forward it to me directly? Thanks, Martin


On 03/17/2017 12:45 PM, Dinakar Kulkarni wrote:

Hello,

The following error was generated while attempting to install the "Rhtslib"
package in R v3.3.2:

/usr/bin/perl: symbol lookup error: /perl-modules/5.18.2/1.142660/x86_64-
linux-2.6-rhel6/lib/perl5/x86_64-linux-thread-multi/auto/List/Util/Util.so:
undefined symbol: Perl_xs_apiversion_bootcheck

WARNING: 'autoconf' is missing on your system.

 You should only need it if you modified 'configure.ac',

 or m4 files included by it.

 The 'autoconf' program is part of the GNU Autoconf package:

 

 It also requires GNU m4 and Perl in order to run:

 

 

make[1]: *** [configure] Error 127

make[1]: Leaving directory `/tmp/Rtmpn6FFZH/R.INSTALL671e
4ed4c86d/Rhtslib/src/htslib'

make: *** [htslib/libhts.la] Error 2

ERROR: compilation failed for package ‘Rhtslib’

On further investigation, I was able to determine that the default Perl
version on the OS (RHEL 6.6) was v5.10.1, so it turned out to be an
incompatibility issue.

I looked into the source for Rhtslib and see that it use these 3 Perl
scripts:

Rhtslib/src/htslib/test/compare_sam.pl
Rhtslib/src/htslib/test/test.pl
Rhtslib/src/htslib/test/test_view.pl

and they use the default env Perl. I believe that it would be better to
specify the Perl version within these scripts(i.e. use v5.18.2) for
compiling/building the package. I've attached suggested patch files here
for the same.

Thanks,
Dinakar.




This email message may contain legally privileged and/or...{{dropped:2}}

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

[R-pkg-devel] How do you discover and learn about R packages?

2017-03-20 Thread Julia Silge 
I am contributing to a session at userR 2017 this coming July that will
focus on discovering and learning about R packages. This is an increasingly
important issue for R users as we all decide which of the 10,000+ packages
to invest time in understanding and then use in our work.

To prepare for this session and gain some understanding, I am running an
online survey about how R users currently discover and learn about R
packages:
http://doo.vote/a87ff60

The question has one multiple select question about how you currently
discover and learn about R packages. If you have other ways that you don’t
feel were fairly covered in the survey options, feel free to reply to me or
leave a comment here on my blog:
http://juliasilge.com/blog/Package-Search/

Thanks,
Julia

[[alternative HTML version deleted]]

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

Re: [Rd] outer not applying a constant function

2017-03-20 Thread William Dunlap via R-devel 
> Or is this a bad idea?

I don't like the proposal.  I have seen code like the following (in
fact, I have written such code, where I had forgotten a function was
not vectorized) where the error would have been discovered much later
if outer() didn't catch it.

  > outer(1:3, 11:13, sum)
  Error in outer(1:3, 11:13, sum) :
dims [product 9] do not match the length of object [1]

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Mar 20, 2017 at 6:36 AM, Martin Maechler
 wrote:
>> Gebhardt, Albrecht 
>> on Sun, 19 Mar 2017 09:14:56 + writes:
>
> > Hi,
> > the function outer can not apply a constant function as in the last 
> line of the following example:
>
> >> xg <- 1:4
> >> yg <- 1:4
> >> fxyg <- outer(xg, yg, function(x,y) x*y)
> >> fconstg <- outer(xg, yg, function(x,y) 1.0)
> > Error in outer(xg, yg, function(x, y) 1) :
> > dims [product 16] do not match the length of object [1]
>
> > Of course there are simpler ways to construct a constant matrix, that 
> is not my point.
>
> > It happens for me in the context of generating matrices of partial 
> derivatives, and if on of these partial derivatives happens to be constant it 
> fails.
>
> > So e.g this works:
>
> > library(Deriv)
> > f <- function(x,y) (x-1.5)*(y-1)*(x-1.8)+(y-1.9)^2*(x-1.1)^3
> > fx <- Deriv(f,"x")
> > fy <- Deriv(f,"y")
> > fxy <- Deriv(Deriv(f,"y"),"x")
> > fxx <- Deriv(Deriv(f,"x"),"x")
> > fyy <- Deriv(Deriv(f,"y"),"y")
>
> > fg   <- outer(xg,yg,f)
> > fxg  <- outer(xg,yg,fx)
> > fyg  <- outer(xg,yg,fy)
> > fxyg <- outer(xg,yg,fxy)
> > fxxg <- outer(xg,yg,fxx)
> > fyyg <- outer(xg,yg,fyy)
>
> > And with
>
> > f <- function(x,y) x+y
>
> > it stops working. Of course I can manually fix this for that special 
> case, but thats not my point. I simply thought "outer" should be able to 
> handle constant functions.
>
> ?outer   clearly states that  FUN  needs to be vectorized
>
> but  function(x,y) 1is not.
>
> It is easy to solve by wrapping the function in Vectorize(.):
>
>> x <- 1:3; y <- 1:4
>
>> outer(x,y, function(x,y) 1)
> Error in dim(robj) <- c(dX, dY) :
>   dims [product 12] do not match the length of object [1]
>
>> outer(x,y, Vectorize(function(x,y) 1))
>  [,1] [,2] [,3] [,4]
> [1,]1111
> [2,]1111
> [3,]1111
>
> 
>
> So, your "should"  above must be read in the sense
>
>   "It really would be convenient here and
>correspond to other "recycling" behavior of R"
>
> and I agree with that, having experienced the same inconvenience
> as you several times in the past.
>
> outer() being a nice R-level function (i.e., no C speed up)
> makes it easy to improve:
>
> Adding something like the line
>
> if(length(robj) == 1L) robj <- rep.int(robj, dX*dY)
>
> beforedim(robj) <- c(dX, dY)   [which gave the error]
>
> would solve the issue and not cost much (in the cases it is unneeded).
>
> Or is this a bad idea?
>
> __
> 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] Experimental CXX_STD problem in R 3.4

2017-03-20 Thread Jeroen Ooms 
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer  wrote:
> I have just added some code to ensure that the compilation fails with an 
> informative error message if a specific C++ standard is requested but the 
> corresponding compiler has not been defined. Please test this.

I can confirm that (at least on Windows) we get a proper error message
for CXX14 and CXX17, eg:

  * installing *source* package 'testcxx' ...
  ** libs
  Error in .shlib_internal(args) :
   C++14 standard requested but CXX1Y is not defined
  * removing 'C:/Program Files/R/R-devel/library/testcxx'

CXX98 still does not work though. It seems SHLIB_CXX98LD is undefined
on Windows?

  * installing *source* package 'testcxx' ...
  ** libs
  c:/Rtools/mingw_64/bin/g++  -std=gnu++98
-I"C:/PROGRA~1/R/R-devel/include" -DNDEBUG
-I"d:/Compiler/gcc-4.9.3/local330/include" -O2 -Wall  -mtune=core2
-c test.cpp -o test.o
  -shared -s -static-libgcc -o testcxx.dll tmp.def test.o
-Ld:/Compiler/gcc-4.9.3/local330/lib/x64
-Ld:/Compiler/gcc-4.9.3/local330/lib -LC:/PROGRA~1/R/R-devel/bin/x64
-lR
  -shared: not found
  no DLL was created
  ERROR: compilation failed for package 'testcxx'

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

Re: [Bioc-devel] developing R package for new release

2017-03-20 Thread James W. MacDonald 
On Fri, Mar 17, 2017 at 3:45 PM, Nicholas Clark 
wrote:

> I’m planning on adding some new features to my package (GRmetrics) before
> this upcoming release and I have a few development questions.
>
>
> 1) Which version of R should I be using? I looked at this page (
> http://bioconductor.org/developers/how-to/useDevel/
> ), but I was still confused as to whether I should use the recently
> released R 3.3.3 or the R-devel 3.4.0 at http://r.research.att.com/


For the spring release you should use R-devel. For the fall release you
should use the most current version of R. This is because we release twice
a year, but R is only released in spring.

Looking at the useDevel page I see that I am simply repeating (almost
verbatim) what is written there. Is there something unclear about this that
we should address? It seems clear enough to me, but I've been doing this a
long time.


>
> .
>
>
> 2) What is the best/easiest way to work with github? Should I fork the
> repository from the read-only Bioconductor repo and work on that or
> maintain a separate repo? Or does it not matter?
>

I believe you should fork the repo from the Bioconductor mirror and use
that. There is some info here (
http://bioconductor.org/developers/how-to/git-mirrors/). But there are some
considerations to be made. Right now, we are using subversion for version
control, and anything you do in github has to be 'subversionized' in order
for your commits to be checked into the main version control repository.
It's far easier IMO to just use subversion to do all your version control,
because you don't have to worry about getting git to talk to subversion.

That said, after the April release we are transitioning to git, so we will
be using git soon enough. But for now I am still using SVN because it's a
direct commit to the main repo. My advice is to use whatever the main repo
is based on, because mixing and matching adds an extra level of complexity
that doesn't appear to have much to offer in return.


>
> 3) Should I make a “release-3.5” branch and commit changes there, or
> should it be “devel”, or just the “master” branch? http://bioconductor.
> org/developers/how-to/git-mirrors/
>  talks about this, but again, it’s not clear to me.
>

You never make your own branches. That's controlled by BioC core. Unless
you are fixing a bug in the release version of your package you should be
using the master branch (or if you use SVN, you should just be checking out
of the trunk,
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/GRmetrics).


>
> 4) It looks like my package is failing the Windows build because it
> requires “SummarizedExperiment”, which is failing the Windows build. Is
> there anything I can do to fix this? Apologies if this has already been
> addressed. The error is: ERROR: dependency ‘SummarizedExperiment’ is not
> available for package ‘GRmetrics' (http://bioconductor.org/
> checkResults/release/bioc-LATEST/GRmetrics/tokay1-buildsrc.html
> )
>

If one of your dependencies is failing, and in particular if the dependency
is maintained by Bioc core, then the best thing to do is wait. If you are
relying on somebody else's package and they are consistently failing you
might contact them and find out if you can help.

Jim



>
> Best,
> Nick Clark
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel




-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

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

Re: [Rd] Experimental CXX_STD problem in R 3.4

2017-03-20 Thread Jeroen Ooms 
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer  wrote:
> I have just added some code to ensure that the compilation fails with an 
> informative error message if a specific C++ standard is requested but the 
> corresponding compiler has not been defined. Please test this.

Are you sure we shouldn't just fall back on a previous standard
instead of failing? For example if the package author has specified a
preference for CXX14 but the compiler only has CXX11, the package
might still build with -std=c++11 (given that C++14 is only a small
extension on the C++11 standard).

The current behavior (in R 3.3) for packages with "CXX_STD=CXX11" is
to fall back on CXX when the compiler does not have CXX1X. Will R-3.4
start failing these packages? This would affect many users on CentOS 6
(gcc 4.4.7).

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

Re: [Rd] Fwd: Possible memory problems with mallloc when called with .C()

2017-03-20 Thread William Dunlap via R-devel 
> void dnk_c(double *sortedFsample, unsigned long int n, unsigned
long int k, double *dKol)

All arguments to C functions called by .C() must be pointers.  Also, R
integers are C ints, not unsigned long ints.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Mar 20, 2017 at 5:55 AM, Hristo Inouzhe Valdes
 wrote:
> Hello,
>
> I'm trying to calculate a certain distance estimator for my thesis. I have a
> program in C that works fine when I call it with .C() in R, but since
> I'm dealing with big matrices like 3x2 it was getting a stack
> overflow. Now I have the same program but more efficeintly coded using
> malloc, and it works perfectlry in C, compiles well with R CMD SHLIB
> but when I call it with .C() my pc basicly stops working independantly
> of the size of the matrices involved.
>
> The C code is the following (sorry it is a bit long):
>
> #include 
> #include 
> #include 
> #include 
> #ifdef NAN
> /* NAN is supported */
> #endif
> #ifdef INFINITY
> /* INFINITY is supported */
> #endif
>
> void dnk_c(double *sortedFsample, unsigned long int n, unsigned
> long int k, double *dKol){
>
>   double min(double a, double b) {
> return (a < b) ? a : b;
>   }
>
>   double max(double a, double b) {
> return (a > b) ? a : b;
>   }
>
>   double r_abs(double a){
> return (a < 0) ? -a : a;
>   }
>
>   int cmp(const void *a, const void *b) {
> return (*(double*)a - *(double*)b);
>   }
>
>   double superior(double x, double i, double m){
> double op1 = r_abs(x-(i)/(m));
> double op2 = r_abs(x-(i-1)/(m));
> return max(op1,op2);
>   }
>
>   double termino1, termino2, f, g, t, h1, h2, l=1.0, m=n-k;
>   unsigned long int i, j, filas;
>
>   double **matrixA, **matrixB;
>
>   matrixA = (double **) malloc((k+1)*sizeof(double *));
>   matrixB = (double **) malloc((k+1)*sizeof(double *));
>
>   for (i=0; i <= k; i++) {
> matrixA[i] = (double *) malloc(n*sizeof(double));
> matrixB[i] = (double *) malloc(n*sizeof(double));
>
> for (j=0; j < n; j++) {
>   matrixA[i][j] = 0;
>   matrixB[i][j] = 0;
> }
>   }
>
>   for (i=0; i j  = k;
> f  = i-m+1;
> l  = 0;
> h2 = min(i,j);
> h1 = max(l,f);
>
> for(; h1 <= h2; h1++) {
>   t = i-h1+1;
>   filas = (unsigned long int) h1;
>   matrixA[filas][i] = superior(sortedFsample[i], t, m);
> }
>   }
>
>   for (i=0; i j  = n-m-1;
> f  = i-m;
> g  = 0;
> h2 = min(i,j);
> h1 = max(g,f);
>
> for(; h1 <= h2; h1++) {
>   t = i-h1+1;
>   filas = (unsigned long int) h1;
>   matrixB[filas][i] = r_abs(sortedFsample[i] - (i-h1)/m);
> }
>   }
>
>
>   i = 1;
>   j = n-m;
>
>   for(; i< n; i++) {
> f  = i-m+1;
> g  = 1;
> h2 = min(i,j);
> h1 = max(g,f);
>
> matrixA[0][i] = max(matrixA[0][i], matrixA[0][i-1]);
>
> for(; h1 <= h2; h1++) {
>   filas = (unsigned long int) h1;
>   termino1 = max(matrixA[filas][i], matrixA[filas][i-1]);
>   termino2 = max(matrixA[filas][i], matrixB[filas-1][i-1]);
>
>   matrixA[filas][i] = min(termino1, termino2);
> }
>
> t  = n-m-1;
> f  = i-m;
> g  = 0;
> h2 = min(i,t);
> h1 = max(g,f);
>
> filas = (unsigned long int) h1;
> matrixB[0][i] = max(matrixB[0][i], matrixA[0][i-1]);
>
> for(; h1 <= h2; h1++) {
>   filas = (unsigned long int) h1;
>   termino1 = max(matrixB[filas][i], matrixA[filas][i-1]);
>
>   if (filas == 0) {
> termino2 = max(matrixB[filas][i], - INFINITY);
>   }
>   else{
> termino2 = max(matrixB[filas][i], matrixB[filas-1][i-1]);
>   }
>   matrixB[filas][i] = min(termino1, termino2);
> }
>   }
>
>   filas = (unsigned long int) t;
>   unsigned long int n_int = (unsigned long int) (n-1);
>   double result = min(matrixA[filas+1][n_int], matrixB[filas][n_int]);
>
>   for (i=0; i <= k; i++) {
> free(matrixA[i]);
> free(matrixB[i]);
>   }
>
>   free(matrixA);
>   free(matrixB);
>
>   dKol[0] = result;
> }
>
> The R CMD SHLIB returns:
>
> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG  -fpic  -g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2 -g  -c
> /home/hristo/pCloudDrive/R/dnk_c.c -o
> /home/hristo/pCloudDrive/R/dnk_c.o
> gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions
> -Wl,-z,relro -o /home/hristo/pCloudDrive/R/dnk_c.so
> /home/hristo/pCloudDrive/R/dnk_c.o -L/usr/lib/R/lib -lR
>
> My call in R to the function is:
>
>

[R-pkg-devel] NOTE with unusual but theoretically allowed person roles

2017-03-20 Thread Miguel Menéndez 
While checking a package as cran with R 3.3.2 (Windows 8 and Ubuntu 16.04),
I am getting a NOTE about person roles which are unusual but theoretically
allowed.


In the DESCRIPTION file I set:

Authors@R: c(
  person("First", "Person", email = "m...@mail.com", role = c("aut", "cre")),
  person("Second", "Person", role = c("dtc", "csl")))
Author: First Person [aut, cre],
  Second Person [dtc, csl]


Then I get a NOTE:

Author field differs from that derived from Authors@R
  Author:'First Person [aut, cre], Second Person [dtc, csl]'
  Authors@R: 'First Person [aut, cre], Second Person [dtc]'

If I delete the role 'csl', the note dissapears.

It seems that R code is not allowing the role 'csl' (Consultant), although
it is in the MARC Code List for Relators (https://www.loc.gov/marc/rela
tors/relaterm.html)

If I run the code in the console, apparently Authors@R and Authors fit, so
I don't understand the NOTE:

> c(person("First", "Person", email = "m...@mail.com", role = c("aut",
"cre")),
  person("Second", "Person", role = c("dtc", "csl")))
[1] "First Person  [aut, cre]"
[2] "Second Person [dtc, csl]"


I get more confused when I run the same code in r-fiddle.org and I get a
different output:
Invalid role specification: 'dtc'.
[1] "First Person  [aut, cre]"
[2] "Second Person [csl]"


I have tried with other roles not included as suggested in ?person, such as
'pdr' (Project director), or 'sad' (Scientific advisor), with the same
problem.


I can just consider the second person as a contributor and go on, but... is
this an expected behavour? What I am doing wrong?

Thanks in advance.

[[alternative HTML version deleted]]

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

[Bioc-devel] developing R package for new release

2017-03-20 Thread Nicholas Clark 
I’m planning on adding some new features to my package (GRmetrics) before this 
upcoming release and I have a few development questions.


1) Which version of R should I be using? I looked at this page 
(http://bioconductor.org/developers/how-to/useDevel/
), but I was still confused as to whether I should use the recently released R 
3.3.3 or the R-devel 3.4.0 at http://r.research.att.com/
.


2) What is the best/easiest way to work with github? Should I fork the 
repository from the read-only Bioconductor repo and work on that or maintain a 
separate repo? Or does it not matter?


3) Should I make a “release-3.5” branch and commit changes there, or should it 
be “devel”, or just the “master” branch? 
http://bioconductor.org/developers/how-to/git-mirrors/
 talks about this, but again, it’s not clear to me.


4) It looks like my package is failing the Windows build because it requires 
“SummarizedExperiment”, which is failing the Windows build. Is there anything I 
can do to fix this? Apologies if this has already been addressed. The error is: 
ERROR: dependency ‘SummarizedExperiment’ is not available for package 
‘GRmetrics' 
(http://bioconductor.org/checkResults/release/bioc-LATEST/GRmetrics/tokay1-buildsrc.html
)


Best,
Nick Clark



[[alternative HTML version deleted]]

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

Re: [Rd] outer not applying a constant function

2017-03-20 Thread Martin Maechler 
> Gebhardt, Albrecht 
> on Sun, 19 Mar 2017 09:14:56 + writes:

> Hi,
> the function outer can not apply a constant function as in the last line 
of the following example:

>> xg <- 1:4
>> yg <- 1:4
>> fxyg <- outer(xg, yg, function(x,y) x*y)
>> fconstg <- outer(xg, yg, function(x,y) 1.0)
> Error in outer(xg, yg, function(x, y) 1) :
> dims [product 16] do not match the length of object [1]

> Of course there are simpler ways to construct a constant matrix, that is 
not my point.

> It happens for me in the context of generating matrices of partial 
derivatives, and if on of these partial derivatives happens to be constant it 
fails.

> So e.g this works:

> library(Deriv)
> f <- function(x,y) (x-1.5)*(y-1)*(x-1.8)+(y-1.9)^2*(x-1.1)^3
> fx <- Deriv(f,"x")
> fy <- Deriv(f,"y")
> fxy <- Deriv(Deriv(f,"y"),"x")
> fxx <- Deriv(Deriv(f,"x"),"x")
> fyy <- Deriv(Deriv(f,"y"),"y")

> fg   <- outer(xg,yg,f)
> fxg  <- outer(xg,yg,fx)
> fyg  <- outer(xg,yg,fy)
> fxyg <- outer(xg,yg,fxy)
> fxxg <- outer(xg,yg,fxx)
> fyyg <- outer(xg,yg,fyy)

> And with

> f <- function(x,y) x+y

> it stops working. Of course I can manually fix this for that special 
case, but thats not my point. I simply thought "outer" should be able to handle 
constant functions.

?outer   clearly states that  FUN  needs to be vectorized

but  function(x,y) 1is not.

It is easy to solve by wrapping the function in Vectorize(.):

> x <- 1:3; y <- 1:4

> outer(x,y, function(x,y) 1)
Error in dim(robj) <- c(dX, dY) : 
  dims [product 12] do not match the length of object [1]

> outer(x,y, Vectorize(function(x,y) 1))
 [,1] [,2] [,3] [,4]
[1,]1111
[2,]1111
[3,]1111



So, your "should"  above must be read in the sense

  "It really would be convenient here and
   correspond to other "recycling" behavior of R"

and I agree with that, having experienced the same inconvenience
as you several times in the past.

outer() being a nice R-level function (i.e., no C speed up)
makes it easy to improve:

Adding something like the line

if(length(robj) == 1L) robj <- rep.int(robj, dX*dY)

beforedim(robj) <- c(dX, dY)   [which gave the error]

would solve the issue and not cost much (in the cases it is unneeded).

Or is this a bad idea?

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

[Rd] IO error when writing to disk

2017-03-20 Thread realitix 
Hello,
Here a small improvement for R.

When you use the function write.table, if the disk is full for example, the
function doesn't return an error and the file is written but truncated.

It can be a source of mistakes because you can then copy the output file
and think everything is ok.

How to reproduce
-

>> write.csv(1:1000, 'path')

You must have a path with a small amount of disk available (on linux:
http://souptonuts.sourceforge.net/quota_tutorial.html)

I have joined the patch in this email.
Can you open a bugzilla account for me to keep track of this change.

Thanks,
Jean-Sébastien Bevilacqua
Index: src/library/utils/src/io.c
===
--- src/library/utils/src/io.c  (révision 72357)
+++ src/library/utils/src/io.c  (copie de travail)
@@ -1120,12 +1120,23 @@
for(int i = 0; i < nr; i++) {
if(i % 1000 == 999) R_CheckUserInterrupt();
if(!isNull(rnames))
-   Rconn_printf(con, "%s%s",
-EncodeElement2(rnames, i, quote_rn, qmethod,
-   , sdec), csep);
+
+   if(Rconn_printf(con, "%s%s", EncodeElement2(rnames, i, 
quote_rn, qmethod, , sdec), csep) < 0) {
+error(_("IO error, cannot write table."));
+break;
+}
+
for(int j = 0; j < nc; j++) {
xj = VECTOR_ELT(x, j);
-   if(j > 0) Rconn_printf(con, "%s", csep);
+
+   if(j > 0) {
+if(Rconn_printf(con, "%s", csep) < 0) {
+error(_("IO error, cannot write table."));
+i = nr;
+break;
+}
+}
+
if(isna(xj, i)) tmp = cna;
else {
if(!isNull(levels[j])) {
@@ -1148,9 +1159,17 @@
 , sdec);
}
}
-   Rconn_printf(con, "%s", tmp);
+
+if(Rconn_printf(con, "%s", tmp) < 0) {
+error(_("IO error, cannot write table."));
+i = nr;
+break;
+}
}
-   Rconn_printf(con, "%s", ceol);
+   if(Rconn_printf(con, "%s", ceol) < 0) {
+error(_("IO error, cannot write table."));
+break;
+}
}
 
 } else { /* A matrix */
@@ -1163,20 +1182,36 @@
 
for(int i = 0; i < nr; i++) {
if(i % 1000 == 999) R_CheckUserInterrupt();
-   if(!isNull(rnames))
-   Rconn_printf(con, "%s%s",
-EncodeElement2(rnames, i, quote_rn, qmethod,
-   , sdec), csep);
+   if(!isNull(rnames)) {
+if(Rconn_printf(con, "%s%s", EncodeElement2(rnames, i, quote_rn, 
qmethod, , sdec), csep) < 0) {
+error(_("IO error, cannot write table."));
+break;
+}
+}
for(int j = 0; j < nc; j++) {
-   if(j > 0) Rconn_printf(con, "%s", csep);
+   if(j > 0) {
+if(Rconn_printf(con, "%s", csep) < 0) {
+error(_("IO error, cannot write table."));
+i = nr;
+break;
+}
+}
if(isna(x, i + j*nr)) tmp = cna;
else {
tmp = EncodeElement2(x, i + j*nr, quote_col[j], qmethod,
, sdec);
}
-   Rconn_printf(con, "%s", tmp);
+if(Rconn_printf(con, "%s", tmp) < 0) {
+error(_("IO error, cannot write table."));
+i = nr;
+break;
+}
}
-   Rconn_printf(con, "%s", ceol);
+
+   if(Rconn_printf(con, "%s", ceol) < 0) {
+error(_("IO error, cannot write table."));
+break;
+}
}
 
 }
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Fwd: Possible memory problems with mallloc when called with .C()

2017-03-20 Thread Hristo Inouzhe Valdes 
Hello,

I'm trying to calculate a certain distance estimator for my thesis. I have a
program in C that works fine when I call it with .C() in R, but since
I'm dealing with big matrices like 3x2 it was getting a stack
overflow. Now I have the same program but more efficeintly coded using
malloc, and it works perfectlry in C, compiles well with R CMD SHLIB
but when I call it with .C() my pc basicly stops working independantly
of the size of the matrices involved.

The C code is the following (sorry it is a bit long):

#include 
#include 
#include 
#include 
#ifdef NAN
/* NAN is supported */
#endif
#ifdef INFINITY
/* INFINITY is supported */
#endif

void dnk_c(double *sortedFsample, unsigned long int n, unsigned
long int k, double *dKol){

  double min(double a, double b) {
return (a < b) ? a : b;
  }

  double max(double a, double b) {
return (a > b) ? a : b;
  }

  double r_abs(double a){
return (a < 0) ? -a : a;
  }

  int cmp(const void *a, const void *b) {
return (*(double*)a - *(double*)b);
  }

  double superior(double x, double i, double m){
double op1 = r_abs(x-(i)/(m));
double op2 = r_abs(x-(i-1)/(m));
return max(op1,op2);
  }

  double termino1, termino2, f, g, t, h1, h2, l=1.0, m=n-k;
  unsigned long int i, j, filas;

  double **matrixA, **matrixB;

  matrixA = (double **) malloc((k+1)*sizeof(double *));
  matrixB = (double **) malloc((k+1)*sizeof(double *));

  for (i=0; i <= k; i++) {
matrixA[i] = (double *) malloc(n*sizeof(double));
matrixB[i] = (double *) malloc(n*sizeof(double));

for (j=0; j < n; j++) {
  matrixA[i][j] = 0;
  matrixB[i][j] = 0;
}
  }

  for (i=0; i