Re: [R-pkg-devel] Link compiled C object to internal package file

2019-06-21 Thread mark padgham

Dear All,

Thanks for the input - it was sufficient for me to figure out a
solution, which I'll briefly describe here for future reference. This
draws primarily on the section of Writing R Extensions quoted by Martin
Morgan below, giving rise to the idea of combining environmental
variables, and the idea of Iñaki Ucar (not posted to list) of defining
functional macros. Then it's quite simple:

1. Use system.file to set environmental variable on package load giving
full path to desired file.

2. Define macro as `#define MY_FILE_PATH getPath()`

3. Define the `getPath()` function as simply `char * getenv
("MY_FILE_PATH");`.

4. Insert `MY_FILE_PATH` macro for every desired reference to locally
packaged file.

Works perfectly! Thanks again,

mark


On 19/06/2019 17:46, Martin Morgan wrote:

Section 1.2 of 'Writing R Extensions' says

Another example is when a package installs support files that are required at 
run time, and their location is substituted into an R data structure at 
installation time. The names of the top-level library directory (i.e., 
specifiable via the ‘-l’ argument) and the directory of the package itself are 
made available to the installation scripts via the two shell/environment 
variables R_LIBRARY_DIR and R_PACKAGE_DIR. Additionally, the name of the 
package (e.g. ‘survival’ or ‘MASS’) being installed is available from the 
environment variable R_PACKAGE_NAME. (Currently the value of R_PACKAGE_DIR is 
always ${R_LIBRARY_DIR}/${R_PACKAGE_NAME}, but this used not to be the case 
when versioned installs were allowed. Its main use is in configure.win scripts 
for the installation path of external software’s DLLs.) Note that the value of 
R_PACKAGE_DIR may contain spaces and other shell-unfriendly characters, and so 
should be quoted in makefiles and configure scripts

which sounds approximately similar to your situation and suggests using the full path 
to the installed file R_PACKAGE_DIR/dict/.

It's not really clear what your two use cases are below, specifically the 
unique circumstances of 'in tests only'. I would guess that a relative path 
would not work, in general, because the path would be relative to the current 
working directory, which of course changes, rather than relative to the path of 
the shared object...

Martin Morgan

On 6/19/19, 10:46 AM, "R-package-devel on behalf of mark padgham" 
 wrote:

 Yeah, but that would require completely rewriting the C code to accept a
 variable for something that is used hundreds of times as a simple macro.
 (Most of that C code is an old library bundled with the package, so not
 my work in that regard.) It would still be enormously easier to robustly
 provide a relative location within the compiled source object to direct
 it to the file ... but how?


 On 19/06/2019 14:10, Jeff Newmiller wrote:
 > What do you mean by
 >
 > "call an external text file"
 >
 > ? Text files are data... do you want to open it and read it? Are you 
familiar with the system.file() function?
 >
 >
 > On June 19, 2019 5:45:51 AM CDT, mark padgham  
wrote:
 >> Dear All,
 >>
 >> I'm developing a package which primarily relies on C code that itself
 >> has to call an external text file representing a dictionary or lookup
 >> table. The location of this file is defined in a C macro, the file
 >> itself packaged in "./inst/dict/" and so currently called
 >> as
 >> "#define mylocation './dict/'". I can load the package and
 >> all works well, yet the tests fail because the compiled object
 >> ("./src/") can not find this file **in tests only**. My
 >> primary request would then be advice for where best to place such files
 >> that need to be called directly by compiled objects, and how to direct
 >> the compiled object to such files? Failing that, advice on why such
 >> attempts at linking compiled objects to external files might fail only
 >> during tests, yet work otherwise, would be appreciated.
 >>
 >> Other important info: Yes, the external dictionary file **must** be
 >> linked directly from the compiled object, not at run time. This means
 >> that no R-based solutions can be implemented, and so the problem can
 >> only be solved in this case through figuring out how to direct a
 >> compiled object to connect to an additional package-internal file.
 >>
 >> Thanks in advance,
 >>
 >> mark
 >>
 >> __
 >> 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] Link compiled C object to internal package file

2019-06-19 Thread Martin Morgan
Section 1.2 of 'Writing R Extensions' says

Another example is when a package installs support files that are required at 
run time, and their location is substituted into an R data structure at 
installation time. The names of the top-level library directory (i.e., 
specifiable via the ‘-l’ argument) and the directory of the package itself are 
made available to the installation scripts via the two shell/environment 
variables R_LIBRARY_DIR and R_PACKAGE_DIR. Additionally, the name of the 
package (e.g. ‘survival’ or ‘MASS’) being installed is available from the 
environment variable R_PACKAGE_NAME. (Currently the value of R_PACKAGE_DIR is 
always ${R_LIBRARY_DIR}/${R_PACKAGE_NAME}, but this used not to be the case 
when versioned installs were allowed. Its main use is in configure.win scripts 
for the installation path of external software’s DLLs.) Note that the value of 
R_PACKAGE_DIR may contain spaces and other shell-unfriendly characters, and so 
should be quoted in makefiles and configure scripts

which sounds approximately similar to your situation and suggests using the 
full path to the installed file R_PACKAGE_DIR/dict/.

It's not really clear what your two use cases are below, specifically the 
unique circumstances of 'in tests only'. I would guess that a relative path 
would not work, in general, because the path would be relative to the current 
working directory, which of course changes, rather than relative to the path of 
the shared object...

Martin Morgan

On 6/19/19, 10:46 AM, "R-package-devel on behalf of mark padgham" 
 
wrote:

Yeah, but that would require completely rewriting the C code to accept a
variable for something that is used hundreds of times as a simple macro.
(Most of that C code is an old library bundled with the package, so not
my work in that regard.) It would still be enormously easier to robustly
provide a relative location within the compiled source object to direct
it to the file ... but how?


On 19/06/2019 14:10, Jeff Newmiller wrote:
> What do you mean by
>
> "call an external text file"
>
> ? Text files are data... do you want to open it and read it? Are you 
familiar with the system.file() function?
>
>
> On June 19, 2019 5:45:51 AM CDT, mark padgham  
wrote:
>> Dear All,
>>
>> I'm developing a package which primarily relies on C code that itself
>> has to call an external text file representing a dictionary or lookup
>> table. The location of this file is defined in a C macro, the file
>> itself packaged in "./inst/dict/" and so currently called
>> as
>> "#define mylocation './dict/'". I can load the package and
>> all works well, yet the tests fail because the compiled object
>> ("./src/") can not find this file **in tests only**. My
>> primary request would then be advice for where best to place such files
>> that need to be called directly by compiled objects, and how to direct
>> the compiled object to such files? Failing that, advice on why such
>> attempts at linking compiled objects to external files might fail only
>> during tests, yet work otherwise, would be appreciated.
>>
>> Other important info: Yes, the external dictionary file **must** be
>> linked directly from the compiled object, not at run time. This means
>> that no R-based solutions can be implemented, and so the problem can
>> only be solved in this case through figuring out how to direct a
>> compiled object to connect to an additional package-internal file.
>>
>> Thanks in advance,
>>
>> mark
>>
>> __
>> 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] Link compiled C object to internal package file

2019-06-19 Thread Iñaki Ucar
On Wed, 19 Jun 2019 at 16:47, mark padgham  wrote:
>
> Yeah, but that would require completely rewriting the C code to accept a
> variable for something that is used hundreds of times as a simple macro.
> (Most of that C code is an old library bundled with the package, so not
> my work in that regard.) It would still be enormously easier to robustly
> provide a relative location within the compiled source object to direct
> it to the file ... but how?

I assume you have something like

#define MYMACRO "path/to/file"

and this MYMACRO is used here and there in the internal library.
Instead, you can set

#define MYMACRO getPath()

and this getPath function is defined somewhere and uses R's C API to
find that file and return the path (does someone know whether the
functionality of system.file() is directly accessible from C?).

Iñaki

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


Re: [R-pkg-devel] Link compiled C object to internal package file

2019-06-19 Thread mark padgham

Yeah, but that would require completely rewriting the C code to accept a
variable for something that is used hundreds of times as a simple macro.
(Most of that C code is an old library bundled with the package, so not
my work in that regard.) It would still be enormously easier to robustly
provide a relative location within the compiled source object to direct
it to the file ... but how?


On 19/06/2019 14:10, Jeff Newmiller wrote:

What do you mean by

"call an external text file"

? Text files are data... do you want to open it and read it? Are you familiar 
with the system.file() function?


On June 19, 2019 5:45:51 AM CDT, mark padgham  wrote:

Dear All,

I'm developing a package which primarily relies on C code that itself
has to call an external text file representing a dictionary or lookup
table. The location of this file is defined in a C macro, the file
itself packaged in "./inst/dict/" and so currently called
as
"#define mylocation './dict/'". I can load the package and
all works well, yet the tests fail because the compiled object
("./src/") can not find this file **in tests only**. My
primary request would then be advice for where best to place such files
that need to be called directly by compiled objects, and how to direct
the compiled object to such files? Failing that, advice on why such
attempts at linking compiled objects to external files might fail only
during tests, yet work otherwise, would be appreciated.

Other important info: Yes, the external dictionary file **must** be
linked directly from the compiled object, not at run time. This means
that no R-based solutions can be implemented, and so the problem can
only be solved in this case through figuring out how to direct a
compiled object to connect to an additional package-internal file.

Thanks in advance,

mark

__
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] Link compiled C object to internal package file

2019-06-19 Thread Jeff Newmiller
What do you mean by

"call an external text file"

? Text files are data... do you want to open it and read it? Are you familiar 
with the system.file() function?


On June 19, 2019 5:45:51 AM CDT, mark padgham  wrote:
>Dear All,
>
>I'm developing a package which primarily relies on C code that itself
>has to call an external text file representing a dictionary or lookup
>table. The location of this file is defined in a C macro, the file
>itself packaged in "./inst/dict/" and so currently called
>as
>"#define mylocation './dict/'". I can load the package and
>all works well, yet the tests fail because the compiled object
>("./src/") can not find this file **in tests only**. My
>primary request would then be advice for where best to place such files
>that need to be called directly by compiled objects, and how to direct
>the compiled object to such files? Failing that, advice on why such
>attempts at linking compiled objects to external files might fail only
>during tests, yet work otherwise, would be appreciated.
>
>Other important info: Yes, the external dictionary file **must** be
>linked directly from the compiled object, not at run time. This means
>that no R-based solutions can be implemented, and so the problem can
>only be solved in this case through figuring out how to direct a
>compiled object to connect to an additional package-internal file.
>
>Thanks in advance,
>
>mark
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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