Re: [R-pkg-devel] MacOS flat namespace
Hi, On 6/5/20 6:17 pm, Fabio Corradini Santander wrote: ... Cutting the long paths of CRAN, the problem looks like (for r-oldrel-osx-x86_64): ... ** testing if installed package can be loaded from temporary location Error: package or namespace load failed for ‘uFTIR’ in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '.../libs/uFTIR.so': dlopen(.../libs/uFTIR.so, 6): Symbol not found: _H5P_CLS_DATASET_CREATE_ID_g Referenced from: .../libs/uFTIR.so Expected in: flat namespace in .../libs/uFTIR.so Error: loading failed _H5P_CLS_DATASET_CREATE_ID_g comes from the HDF5 library. You don't seem to use it directly, and is probably a transitive dependency coming from gdal, which you do link against, so it seems more like a problem with gdal, not with your code. You could double check this by trying to compile anything else against that gdal installation and see if it works, or the fact that you are compiling an R package. You will find many people on internet having exactly the same problem but in other products, not R. It seems to boil down to a mismatch in how hdf5 was compiled, and how hdf5 users (in this case, gdal) compile against the library (with/without defining the H5_BUILT_AS_DYNAMIC_LIB preprocessor macro). But again, this is probably on gdal's side, not yours. Make sure you have a proper gdal installation; after that things should work. If you want you could be more defensive about this, and add some logic to your configure script to test if a binary compiled against gdal runs correctly or not, and react accordingly (e.g., if gdal is a strong dependency then you don't continue further into the compilation of your package). (The missing symbol for r-release-osx-x86_64 is a different one: _jpeg_resync_to_restart) No idea, but I'd suspect gdal here again, not your code. Cheers, Rodrigo __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] defining r audio connections
What's the gist of the problem of making/having this part of the public API? Is it security, is it stability, is it that the current API is under construction, is it a worry about maintenance load for R Core, ...? Do we know why? It sounds like it's a feature that is useful. I think we missed out on some great enhancements in the past because of it not being part of the public API. /Henrik On Wed, May 6, 2020, 16:26 Martin Morgan wrote: > yep, you're right, after some initial clean-up and running with or without > --as-cran R CMD check gives a NOTE > > * checking compiled code > File ‘socketeer/libs/socketeer.so’: > Found non-API calls to R: ‘R_GetConnection’, >‘R_new_custom_connection’ > > Compiled code should not call non-API entry points in R. > > See 'Writing portable packages' in the 'Writing R Extensions' manual. > > Connections in general seem more useful than ad-hoc functions, though > perhaps for Frederick's use case Duncan's suggestion is sufficient. For > non-CRAN packages I personally would implement a connection. > > (I mistakenly thought this was a more specialized mailing list; I wouldn't > have posted to R-devel on this topic otherwise) > > Martin Morgan > > On 5/6/20, 4:12 PM, "Gábor Csárdi" wrote: > > AFAIK that API is not allowed on CRAN. It triggers a NOTE or a > WARNING, and your package will not be published. > > Gabor > > On Wed, May 6, 2020 at 9:04 PM Martin Morgan > wrote: > > > > The public connection API is defined in > > > > > https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h > > > > I'm not sure of a good pedagogic example; people who want to write > their own connections usually want to do so for complicated reasons! > > > > This is my own abandoned attempt > https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192 > where connection_local_client() is called from R and _connection_local() > creates and populates the appropriate structure. Probably I have done > things totally wrong (e.g., by not checking the version of the API, as > advised in the header file!) > > > > Martin Morgan > > > > On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" < > r-devel-boun...@r-project.org on behalf of murdoch.dun...@gmail.com> > wrote: > > > > On 06/05/2020 1:09 p.m., frede...@ofb.net wrote: > > > Dear R Devel, > > > > > > Since Linux moved away from using a file-system interface for > audio, I think it is necessary to write special libraries to interface with > audio hardware from various languages on Linux. > > > > > > In R, it seems like the appropriate datatype for a `snd_pcm_t` > handle pointing to an open ALSA source or sink would be a "connection". > Connection types are already defined in R for "file", "url", "pipe", > "fifo", "socketConnection", etc. > > > > > > Is there a tutorial or an example package where a new type of > connection is defined, so that I can see how to do this properly in a > package? > > > > > > I can see from the R source that, for example, `do_gzfile` is > defined in `connections.c` and referenced in `names.c`. However, I thought > I should ask here first in case there is a better place to start, than > trying to copy this code. > > > > > > I only want an object that I can use `readBin` and `writeBin` > on, to read and write audio data using e.g. `snd_pcm_writei` which is part > of the `alsa-lib` package. > > > > I don't think R supports user-defined connections, but probably > writing > > readBin and writeBin equivalents specific to your library > wouldn't be > > any harder than creating a connection. For those, you will > probably > > want to work with an "external pointer" (see Writing R > Extensions). > > Rcpp probably has support for these if you're working in C++. > > > > Duncan Murdoch > > > > __ > > 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 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] defining r audio connections
yep, you're right, after some initial clean-up and running with or without --as-cran R CMD check gives a NOTE * checking compiled code File ‘socketeer/libs/socketeer.so’: Found non-API calls to R: ‘R_GetConnection’, ‘R_new_custom_connection’ Compiled code should not call non-API entry points in R. See 'Writing portable packages' in the 'Writing R Extensions' manual. Connections in general seem more useful than ad-hoc functions, though perhaps for Frederick's use case Duncan's suggestion is sufficient. For non-CRAN packages I personally would implement a connection. (I mistakenly thought this was a more specialized mailing list; I wouldn't have posted to R-devel on this topic otherwise) Martin Morgan On 5/6/20, 4:12 PM, "Gábor Csárdi" wrote: AFAIK that API is not allowed on CRAN. It triggers a NOTE or a WARNING, and your package will not be published. Gabor On Wed, May 6, 2020 at 9:04 PM Martin Morgan wrote: > > The public connection API is defined in > > https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h > > I'm not sure of a good pedagogic example; people who want to write their own connections usually want to do so for complicated reasons! > > This is my own abandoned attempt https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192 where connection_local_client() is called from R and _connection_local() creates and populates the appropriate structure. Probably I have done things totally wrong (e.g., by not checking the version of the API, as advised in the header file!) > > Martin Morgan > > On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" wrote: > > On 06/05/2020 1:09 p.m., frede...@ofb.net wrote: > > Dear R Devel, > > > > Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux. > > > > In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc. > > > > Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package? > > > > I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code. > > > > I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package. > > I don't think R supports user-defined connections, but probably writing > readBin and writeBin equivalents specific to your library wouldn't be > any harder than creating a connection. For those, you will probably > want to work with an "external pointer" (see Writing R Extensions). > Rcpp probably has support for these if you're working in C++. > > Duncan Murdoch > > __ > 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] defining r audio connections
AFAIK that API is not allowed on CRAN. It triggers a NOTE or a WARNING, and your package will not be published. Gabor On Wed, May 6, 2020 at 9:04 PM Martin Morgan wrote: > > The public connection API is defined in > > https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h > > I'm not sure of a good pedagogic example; people who want to write their own > connections usually want to do so for complicated reasons! > > This is my own abandoned attempt > https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192 > where connection_local_client() is called from R and _connection_local() > creates and populates the appropriate structure. Probably I have done things > totally wrong (e.g., by not checking the version of the API, as advised in > the header file!) > > Martin Morgan > > On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" > wrote: > > On 06/05/2020 1:09 p.m., frede...@ofb.net wrote: > > Dear R Devel, > > > > Since Linux moved away from using a file-system interface for audio, I > think it is necessary to write special libraries to interface with audio > hardware from various languages on Linux. > > > > In R, it seems like the appropriate datatype for a `snd_pcm_t` handle > pointing to an open ALSA source or sink would be a "connection". Connection > types are already defined in R for "file", "url", "pipe", "fifo", > "socketConnection", etc. > > > > Is there a tutorial or an example package where a new type of > connection is defined, so that I can see how to do this properly in a package? > > > > I can see from the R source that, for example, `do_gzfile` is defined > in `connections.c` and referenced in `names.c`. However, I thought I should > ask here first in case there is a better place to start, than trying to copy > this code. > > > > I only want an object that I can use `readBin` and `writeBin` on, to > read and write audio data using e.g. `snd_pcm_writei` which is part of the > `alsa-lib` package. > > I don't think R supports user-defined connections, but probably writing > readBin and writeBin equivalents specific to your library wouldn't be > any harder than creating a connection. For those, you will probably > want to work with an "external pointer" (see Writing R Extensions). > Rcpp probably has support for these if you're working in C++. > > Duncan Murdoch > > __ > 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] defining r audio connections
The public connection API is defined in https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Connections.h I'm not sure of a good pedagogic example; people who want to write their own connections usually want to do so for complicated reasons! This is my own abandoned attempt https://github.com/mtmorgan/socketeer/blob/b0a1448191fe5f79a3f09d1f939e1e235a22cf11/src/connection.c#L169-L192 where connection_local_client() is called from R and _connection_local() creates and populates the appropriate structure. Probably I have done things totally wrong (e.g., by not checking the version of the API, as advised in the header file!) Martin Morgan On 5/6/20, 2:26 PM, "R-devel on behalf of Duncan Murdoch" wrote: On 06/05/2020 1:09 p.m., frede...@ofb.net wrote: > Dear R Devel, > > Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux. > > In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc. > > Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package? > > I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code. > > I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package. I don't think R supports user-defined connections, but probably writing readBin and writeBin equivalents specific to your library wouldn't be any harder than creating a connection. For those, you will probably want to work with an "external pointer" (see Writing R Extensions). Rcpp probably has support for these if you're working in C++. Duncan Murdoch __ 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] defining r audio connections
On 06/05/2020 1:09 p.m., frede...@ofb.net wrote: Dear R Devel, Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux. In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc. Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package? I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code. I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package. I don't think R supports user-defined connections, but probably writing readBin and writeBin equivalents specific to your library wouldn't be any harder than creating a connection. For those, you will probably want to work with an "external pointer" (see Writing R Extensions). Rcpp probably has support for these if you're working in C++. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] defining r audio connections
Dear R Devel, Since Linux moved away from using a file-system interface for audio, I think it is necessary to write special libraries to interface with audio hardware from various languages on Linux. In R, it seems like the appropriate datatype for a `snd_pcm_t` handle pointing to an open ALSA source or sink would be a "connection". Connection types are already defined in R for "file", "url", "pipe", "fifo", "socketConnection", etc. Is there a tutorial or an example package where a new type of connection is defined, so that I can see how to do this properly in a package? I can see from the R source that, for example, `do_gzfile` is defined in `connections.c` and referenced in `names.c`. However, I thought I should ask here first in case there is a better place to start, than trying to copy this code. I only want an object that I can use `readBin` and `writeBin` on, to read and write audio data using e.g. `snd_pcm_writei` which is part of the `alsa-lib` package. Thank you very much, Frederick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[R-pkg-devel] MacOS flat namespace
Hi, Two months ago I released a package I developed in Debian 9 GCC ( https://CRAN.R-project.org/package=uFTIR). The package was accepted on CRAN, and it can be installed on Windows and Linux machines. However, it is not working on MacOS. I don't know why. The problem starts after the installation, as the OS cannot load the compiled code. Cutting the long paths of CRAN, the problem looks like (for r-oldrel-osx-x86_64): ... ** testing if installed package can be loaded from temporary location Error: package or namespace load failed for ‘uFTIR’ in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '.../libs/uFTIR.so': dlopen(.../libs/uFTIR.so, 6): Symbol not found: _H5P_CLS_DATASET_CREATE_ID_g Referenced from: .../libs/uFTIR.so Expected in: flat namespace in .../libs/uFTIR.so Error: loading failed ... (The missing symbol for r-release-osx-x86_64 is a different one: _jpeg_resync_to_restart) I saw this thread (https://github.com/RcppCore/RcppArmadillo/issues/224) about Rcpp, but CRAN is not using gcc, but clang, so it is not really the same... although I was lost when they discussed about libc++ and libstdc++. I also saw this thread from stackoverflow ( https://stackoverflow.com/questions/40922814/error-in-dyn-loaddllfile-unable-to-load-shared-object-expected-in-flat-na) but I don't have a mix between cpp and plain c. I think that probably has to do with my Makevars file ( https://community.rstudio.com/t/error-during-the-installation-of-utf8-package/4005/2)... maybe I shouldn't use PKG_LIBS and LDLIBS instead? But if I change it, how will it affect the -already successful- installations on windows and linux? The Makevars for Mac and Linux is: CXX_STD = CXX11 PKG_CXXFLAGS = $(SHLIB_OPENMP_CXXFLAGS) `pkg-config --cflags gdal` PKG_LIBS = $(SHLIB_OPENMP_CXXFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) `pkg-config --libs gdal` I will appreciate a hint, Fabio. -- [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
