Re: [Rd] S3 methods in default namespace

[Hadley Wickham]

>> So doesn't that break packages that use S3 but don't have a NAMESPACE?
>
> Maybe, but since the methods are exported as functions they are also found
> for method dispatch and imported, if another package imports from the
> Namspace. The problem I see is what happens if method dispatch is done on a
> package that is not attached but just the Namespace is only loaded.
>
> Anyway, we should really recommend that package authors write NAMESPACE
> files in case their packages are not trivial.
> Note that there are many CRAN packages that fail under R-devel, some of them
> sue to NAMESPACE issues.

I'm not sure I understand the approach of providing a default
NAMESPACE.  Why not just make it a requirement to pass R CMD check?
That seems like it would be a safer approach, although it would create
some work for people who have not yet started using namespaces.

Hadley


-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

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

Re: [Rd] S3 methods in default namespace

[Uwe Ligges]

On 29.08.2011 14:20, Hadley Wickham wrote:

So doesn't that break packages that use S3 but don't have a NAMESPACE?


Maybe, but since the methods are exported as functions they are also found
for method dispatch and imported, if another package imports from the
Namspace. The problem I see is what happens if method dispatch is done on a
package that is not attached but just the Namespace is only loaded.

Anyway, we should really recommend that package authors write NAMESPACE
files in case their packages are not trivial.
Note that there are many CRAN packages that fail under R-devel, some of them
sue to NAMESPACE issues.


I'm not sure I understand the approach of providing a default
NAMESPACE.  Why not just make it a requirement to pass R CMD check?
That seems like it would be a safer approach, although it would create
some work for people who have not yet started using namespaces.


Making it an requirement would certainly be the cleanest approach, but 
there are other constraints. One of them CRAN maintainability. Example: 
Consider some people do not fix packages in time that are in the list of 
dependencies of others, then the whole hierarchy is broken. We try to 
make the transition a bit more smoothly.



Uwe



Hadley




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

Re: [Rd] S3 methods in default namespace

[Duncan Murdoch]

On 29/08/2011 8:20 AM, Hadley Wickham wrote:

>>  So doesn't that break packages that use S3 but don't have a NAMESPACE?
>
>  Maybe, but since the methods are exported as functions they are also found
>  for method dispatch and imported, if another package imports from the
>  Namspace. The problem I see is what happens if method dispatch is done on a
>  package that is not attached but just the Namespace is only loaded.
>
>  Anyway, we should really recommend that package authors write NAMESPACE
>  files in case their packages are not trivial.
>  Note that there are many CRAN packages that fail under R-devel, some of them
>  sue to NAMESPACE issues.

I'm not sure I understand the approach of providing a default
NAMESPACE.  Why not just make it a requirement to pass R CMD check?
That seems like it would be a safer approach, although it would create
some work for people who have not yet started using namespaces.


About 1000 packages on CRAN didn't have a NAMESPACE file.  Most of them 
were very simple so our default NAMESPACE is sufficient.  Some of them 
were not so simple, and those ones really need to have a NAMESPACE.


Adding the namespace makes all of the packages more predictable and 
reliable (because it gives a defined search order for functions), but 
there's no point forcing 1000 package authors to do it if it can be done 
automatically.  However, there are at least a few dozen who should have 
done it long ago, and those ones will need to do it to pass checks.


Duncan Murdoch

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

[Rd] R-loadable dll with minGW-compiled linked library

[Ilana Lichtenstein]

I am trying to create a dynamic library (dll) for loading into R with
dyn.load command.

I am trying to use the library libdai (a machine learning C++ library) and
boost (C++ libraries) in my main C++ program. While I am able to compile the
main C++ file I am using successfully into a dll, there is a problem linking
to libraries (libdai.a) and boost libraries. I only have instructions on how
to compile these libraries with cygwin - NOT with minGW tools, as required
by Rtools and R for correct dll creation and loading.

Currently I have R CMD SHLIB configured as follows:

(To create object file)
/g++  -c -Wno-deprecated -Wall -W -Wextra -DCYGWIN
-O3 -I  -I -o  example.o

(To create shared library)
example examples/example.cpp
/g++ -shared -s static-libgcc -o example.dll
example.o -L.../libdai/lib -ldai -L"C:/cygwin/lib" -lcygwin

Including the -lcygwin library is necessary for compilation without linker
error. However, it causes dyn.load to "hang" when used in R.


The tutorials on the web regarding creation of C++ dlls do not discuss
linking to libraries.



Thus my two questions are:
(1) Does anyone know how to compile a C++ program which links to a library,
which dyn.load will accept? What flags are required in the R makeconf? How
do you link in a library to the dll?  What flags must I compile the libdai
and boost libraries with?
(2) If my interfacing issue cannot be resolved, does anyone know any tools
that interface to R that do machine learning belief propagation?

Any help is appreciated.

Ilana Lichtenstein
PhD Candidate
School of IT
University of Sydney

[[alternative HTML version deleted]]

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

Re: [Rd] R-loadable dll with minGW-compiled linked library

[Dirk Eddelbuettel]

On 30 August 2011 at 02:25, Ilana Lichtenstein wrote:
| The tutorials on the web regarding creation of C++ dlls do not discuss
| linking to libraries.

Well, there are working examples among the 3200+ CRAN packages...

| Thus my two questions are:
| (1) Does anyone know how to compile a C++ program which links to a library,
| which dyn.load will accept? What flags are required in the R makeconf? How
| do you link in a library to the dll?  What flags must I compile the libdai
| and boost libraries with?

Sure. I am as self-centered as the next guy so I welcome you to look at my
RQuantLib project (on CRAN and R-Forge) which has been doing that for a
decade -- and the QuantLib project / library itself uses parts of Boost. 

Moreover, Rcpp is a package whose goal it is to make C++ interchange from /
to R a little less painful.  There are now three dozen packages on CRAN using
it (see the 'reverse depends' via the Rcpp CRAN page) and several of these
link to other external libraries.

[ All that said, I suspect you need to build everything with MinGW. You
certainly cannot mix object code generated via compilers from the visual
whichever suites (as C++ function headers get mangled) and I am pretty
certain that Cygwin's g++ may be doomed for the same reason. I'd be happy to
be convinced otherwise; this would be something worth documenting better. ]

| (2) If my interfacing issue cannot be resolved, does anyone know any tools
| that interface to R that do machine learning belief propagation?

Did you look at the machine learning Task View ?

Dirk


-- 
Two new Rcpp master classes for R and C++ integration scheduled for 
New York (Sep 24) and San Francisco (Oct 8), more details are at
http://dirk.eddelbuettel.com/blog/2011/08/04#rcpp_classes_2011-09_and_2011-10
http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php

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

[Rd] How to safely using OpenMP pragma inside a .C() function?

[Alireza Mahani]

I am trying to parallelize part of a C function that is called from R (via
.C) using OpenMP's "parallel for" pragma. I get mixed results: some runs
finish with no problem, but some lead to R crashing after issuing a long
error message involving memory violations.

I found this post, which describes how a .Call() function can be made to
avoid crashing R by raising the stack limit:

http://www.r-bloggers.com/using-openmp-ized-c-code-with-r/

However, trying this in my .C function doesn't help things. Any
suggestions/tips on whether I can safely use OpenMP inside a .C function,
and if yes how?

Thank you,
Alireza Mahani

--
View this message in context: 
http://r.789695.n4.nabble.com/How-to-safely-using-OpenMP-pragma-inside-a-C-function-tp3777036p3777036.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] http://cran.r-project.org/src/base/NEWS.html points to R v2.13.0

[Henrik Bengtsson]

FYI,

http://cran.r-project.org/src/base/NEWS.html [May 18, 2011] is for R
v2.13.0 whereas http://cran.r-project.org/src/base/NEWS [July 8, 2011]
is for R v2.13.1.  The former is linked to on a few places on
http://cran.r-project.org/.

/Henrik

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

[Rd] Out-of-date manual or small bug in R CMD check?

[Gabriel Becker]

Hey all,

I get a warning about an unsupported file type in the data directory during
R CMD check (for R 2.13.1) if I use the save function to create an Rdata,
but if I save the same object to a .rda file, no warning.

Section 1.1.5 (pg 11 of the pdf) of the Writing R Extensions manual (2.13.1)
appears to say that .Rdata files should be fine:

" Data files can have one of three types as indicated by their extension:
plain R code (‘.R’ or
‘.r’), tables (‘.tab’, ‘.txt’, or ‘.csv’, see ?data for the file formats,
and note that ‘.csv’ is not
the standard14 CSV format), or save() images (‘.RData’ or ‘.rda’). "

Am I misunderstanding some difference between .rda and .Rdata files in terms
of the save calls, or should R CMD check and the extensions manual agree on
this?

Thanks for all your hard work.
~G

SessionInfo:

R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-linux-gnu (64-bit)

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

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

other attached packages:
[1] gridSVG_0.5-10  ProteinVis_0.4  latticeExtra_0.6-18
[4] RColorBrewer_1.0-2  lattice_0.19-33
-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

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

Re: [Rd] Out-of-date manual or small bug in R CMD check?

[Duncan Murdoch]

On 11-08-29 6:37 PM, Gabriel Becker wrote:

Hey all,

I get a warning about an unsupported file type in the data directory during
R CMD check (for R 2.13.1) if I use the save function to create an Rdata,
but if I save the same object to a .rda file, no warning.

Section 1.1.5 (pg 11 of the pdf) of the Writing R Extensions manual (2.13.1)
appears to say that .Rdata files should be fine:

" Data files can have one of three types as indicated by their extension:
plain R code (‘.R’ or
‘.r’), tables (‘.tab’, ‘.txt’, or ‘.csv’, see ?data for the file formats,
and note that ‘.csv’ is not
the standard14 CSV format), or save() images (‘.RData’ or ‘.rda’). "

Am I misunderstanding some difference between .rda and .Rdata files in terms
of the save calls, or should R CMD check and the extensions manual agree on
this?


.RData and .Rdata aren't the same.

Duncan Murdoch



Thanks for all your hard work.
~G

SessionInfo:

R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-linux-gnu (64-bit)

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

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

other attached packages:
[1] gridSVG_0.5-10  ProteinVis_0.4  latticeExtra_0.6-18
[4] RColorBrewer_1.0-2  lattice_0.19-33



__
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] How to safely using OpenMP pragma inside a .C() function?

[Simon Urbanek]

On Aug 29, 2011, at 7:48 PM, Alireza Mahani wrote:

> I am trying to parallelize part of a C function that is called from R (via
> .C) using OpenMP's "parallel for" pragma. I get mixed results: some runs
> finish with no problem, but some lead to R crashing after issuing a long
> error message involving memory violations.
> 

You'll have to provide the code. In general it works (even R uses it itself), 
but there are strict requirements (no R API calls) that you must adhere to.


> I found this post, which describes how a .Call() function can be made to
> avoid crashing R by raising the stack limit:
> 
> http://www.r-bloggers.com/using-openmp-ized-c-code-with-r/
> 

I skimmed through the post and all of the examples are broken - they will only 
work (incidentally) as R internals, not officially (and they are unnecessary 
inefficient).


> However, trying this in my .C function doesn't help things. Any
> suggestions/tips on whether I can safely use OpenMP inside a .C function,
> and if yes how?
> 

There are issues with OpenMP on some platforms in general (in fact pretty much 
every platform had some issue at some point in time), but apart from those you 
only have to make sure that you declare shared/private variables properly and 
don't use *any* R API calls in the parallel part (this includes things like 
LENGTH, REAL, ...).

Cheers,
Simon



> Thank you,
> Alireza Mahani
> 
> --
> View this message in context: 
> http://r.789695.n4.nabble.com/How-to-safely-using-OpenMP-pragma-inside-a-C-function-tp3777036p3777036.html
> Sent from the R devel mailing list archive at Nabble.com.
> 
> __
> 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] Out-of-date manual or small bug in R CMD check?

[Gabriel Becker]

On Mon, Aug 29, 2011 at 5:30 PM, Duncan Murdoch wrote:

> On 11-08-29 6:37 PM, Gabriel Becker wrote:
>
>> Hey all,
>>
>> I get a warning about an unsupported file type in the data directory
>> during
>> R CMD check (for R 2.13.1) if I use the save function to create an Rdata,
>> but if I save the same object to a .rda file, no warning.
>>
>> Section 1.1.5 (pg 11 of the pdf) of the Writing R Extensions manual
>> (2.13.1)
>> appears to say that .Rdata files should be fine:
>>
>> " Data files can have one of three types as indicated by their extension:
>> plain R code (‘.R’ or
>> ‘.r’), tables (‘.tab’, ‘.txt’, or ‘.csv’, see ?data for the file formats,
>> and note that ‘.csv’ is not
>> the standard14 CSV format), or save() images (‘.RData’ or ‘.rda’). "
>>
>> Am I misunderstanding some difference between .rda and .Rdata files in
>> terms
>> of the save calls, or should R CMD check and the extensions manual agree
>> on
>> this?
>>
>
> .RData and .Rdata aren't the same.
>

Ah. My mistake. Sorry for the noise.


>
> Duncan Murdoch
>
>
>> Thanks for all your hard work.
>> ~G
>>
>> SessionInfo:
>>
>> R version 2.13.1 (2011-07-08)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>> locale:
>>  [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
>>  [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
>>  [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8
>>  [7] LC_PAPER=en_US.utf8   LC_NAME=C
>>  [9] LC_ADDRESS=C  LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] grid  stats graphics  grDevices utils datasets  methods
>> [8] base
>>
>> other attached packages:
>> [1] gridSVG_0.5-10  ProteinVis_0.4  latticeExtra_0.6-18
>> [4] RColorBrewer_1.0-2  lattice_0.19-33
>>
>>
>>
>> __**
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel
>>
>
>


-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

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