Colleagues
During the transition to R3.0.0 (OS X), one of the packages that I used --
SASxport -- did not work until I used the "type=source" option in
install.packages.
This led to an adventure:
1. I downloaded the package source: SASxport_1.2.4.tar.gz
2. in the SASxport/R folder, I found all the functions that are part of the
package.
I became interested in whether I could "source" these functions
directly into R and re-create the functionality of the package without
installing/"require"ing the package.
This started with some success until I encountered one problem that I could not
overcome.
When I executed the function write.xport, I received the following error
message:
Error in .C("fill_file_header", cDate = xport.dateFMT(cDate), mDate =
xport.dateFMT(mDate), :
C symbol name "fill_file_header" not in load table
This appears to be coming from the following line of code in write.xport:
out(xport.file.header( cDate = cDate, sasVer = sasVer, osType = osType))
The problem appears to be in
xport.file.header
for which the entire code is:
xport.file.header <-
function(cDate=Sys.time(), mDate=cDate, sasVer="7.00",
osType="Unknown" )
{
.C("fill_file_header",
cDate = xport.dateFMT(cDate), # Creation date
mDate = xport.dateFMT(mDate), # Modification date
sasVer = toupper(as.character(sasVer)), # SAS version number
osType = as.character(osType) # Operating System (can include lowercase)
)
.Call("getRawBuffer", PACKAGE="SASxport")
}
Of note, I commented out the line:
.Call("getRawBuffer", PACKAGE="SASxport")
and the same error occurred (I did not expect this is solve the problem).
I then looked in SASxport/src and found three files (which appear to be coded in
C):
init.c
writeSAS.c
writeSAS.h
that refer to "fill_file_header"
I suspect that these files need to be accessed in some manner in order for
xport.file.header and other functions to work correctly.
The question is how do I access these files:
Do I "source" them in some manner?
Put them in a particular location where they are sourced automatically?
I tried dyn.load but that does not appear to be the correct approach.
Any help would be greatly appreciated.
Thanks
Dennis
Dennis Fisher MD
P < (The "P Less Than" Company)
Phone: 1-866-PLessThan (1-866-753-7784)
Fax: 1-866-PLessThan (1-866-753-7784)
www.PLessThan.com
Hi Dennis, Out of curiosity, what is the purpose of this exercise? Best, Ista On Thu, Apr 11, 2013 at 2:34 PM, Fisher Dennis <fisher at plessthan.com> wrote:> Colleagues > > During the transition to R3.0.0 (OS X), one of the packages that I used -- SASxport -- did not work until I used the "type=source" option in install.packages. > > This led to an adventure: > 1. I downloaded the package source: SASxport_1.2.4.tar.gz > 2. in the SASxport/R folder, I found all the functions that are part of the package. > I became interested in whether I could "source" these functions directly into R and re-create the functionality of the package without installing/"require"ing the package. > > This started with some success until I encountered one problem that I could not overcome. > When I executed the function write.xport, I received the following error message: > Error in .C("fill_file_header", cDate = xport.dateFMT(cDate), mDate = xport.dateFMT(mDate), : > C symbol name "fill_file_header" not in load table > > This appears to be coming from the following line of code in write.xport: > out(xport.file.header( cDate = cDate, sasVer = sasVer, osType = osType)) > The problem appears to be in > xport.file.header > for which the entire code is: > > xport.file.header <- > function(cDate=Sys.time(), mDate=cDate, sasVer="7.00", osType="Unknown" ) > { > .C("fill_file_header", > cDate = xport.dateFMT(cDate), # Creation date > mDate = xport.dateFMT(mDate), # Modification date > sasVer = toupper(as.character(sasVer)), # SAS version number > osType = as.character(osType) # Operating System (can include lowercase) > ) > > .Call("getRawBuffer", PACKAGE="SASxport") > > } > > Of note, I commented out the line: > .Call("getRawBuffer", PACKAGE="SASxport") > and the same error occurred (I did not expect this is solve the problem). > > I then looked in SASxport/src and found three files (which appear to be coded in C): > init.c > writeSAS.c > writeSAS.h > that refer to "fill_file_header" > > I suspect that these files need to be accessed in some manner in order for xport.file.header and other functions to work correctly. > The question is how do I access these files: > Do I "source" them in some manner? > Put them in a particular location where they are sourced automatically? > I tried dyn.load but that does not appear to be the correct approach. > > Any help would be greatly appreciated. > > Thanks > > Dennis > > > Dennis Fisher MD > P < (The "P Less Than" Company) > Phone: 1-866-PLessThan (1-866-753-7784) > Fax: 1-866-PLessThan (1-866-753-7784) > www.PLessThan.com > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code.
On Thu, Apr 11, 2013 at 2:42 PM, Fisher Dennis <fisher at plessthan.com> wrote:> to learn how to use .C()Have you read the manual? http://cran.r-project.org/doc/manuals/R-exts.html#System-and-foreign-language-interfaces Best, Ista> Dennis Fisher MD > P < (The "P Less Than" Company) > Phone: 1-866-PLessThan (1-866-753-7784) > Fax: 1-866-PLessThan (1-866-753-7784) > www.PLessThan.com > > > > On Apr 11, 2013, at 11:40 AM, Ista Zahn <istazahn at gmail.com> wrote: > >> Hi Dennis, >> >> Out of curiosity, what is the purpose of this exercise? >> >> Best, >> Ista >> >> On Thu, Apr 11, 2013 at 2:34 PM, Fisher Dennis <fisher at plessthan.com> wrote: >>> Colleagues >>> >>> During the transition to R3.0.0 (OS X), one of the packages that I used -- SASxport -- did not work until I used the "type=source" option in install.packages. >>> >>> This led to an adventure: >>> 1. I downloaded the package source: SASxport_1.2.4.tar.gz >>> 2. in the SASxport/R folder, I found all the functions that are part of the package. >>> I became interested in whether I could "source" these functions directly into R and re-create the functionality of the package without installing/"require"ing the package. >>> >>> This started with some success until I encountered one problem that I could not overcome. >>> When I executed the function write.xport, I received the following error message: >>> Error in .C("fill_file_header", cDate = xport.dateFMT(cDate), mDate = xport.dateFMT(mDate), : >>> C symbol name "fill_file_header" not in load table >>> >>> This appears to be coming from the following line of code in write.xport: >>> out(xport.file.header( cDate = cDate, sasVer = sasVer, osType = osType)) >>> The problem appears to be in >>> xport.file.header >>> for which the entire code is: >>> >>> xport.file.header <- >>> function(cDate=Sys.time(), mDate=cDate, sasVer="7.00", osType="Unknown" ) >>> { >>> .C("fill_file_header", >>> cDate = xport.dateFMT(cDate), # Creation date >>> mDate = xport.dateFMT(mDate), # Modification date >>> sasVer = toupper(as.character(sasVer)), # SAS version number >>> osType = as.character(osType) # Operating System (can include lowercase) >>> ) >>> >>> .Call("getRawBuffer", PACKAGE="SASxport") >>> >>> } >>> >>> Of note, I commented out the line: >>> .Call("getRawBuffer", PACKAGE="SASxport") >>> and the same error occurred (I did not expect this is solve the problem). >>> >>> I then looked in SASxport/src and found three files (which appear to be coded in C): >>> init.c >>> writeSAS.c >>> writeSAS.h >>> that refer to "fill_file_header" >>> >>> I suspect that these files need to be accessed in some manner in order for xport.file.header and other functions to work correctly. >>> The question is how do I access these files: >>> Do I "source" them in some manner? >>> Put them in a particular location where they are sourced automatically? >>> I tried dyn.load but that does not appear to be the correct approach. >>> >>> Any help would be greatly appreciated. >>> >>> Thanks >>> >>> Dennis >>> >>> >>> Dennis Fisher MD >>> P < (The "P Less Than" Company) >>> Phone: 1-866-PLessThan (1-866-753-7784) >>> Fax: 1-866-PLessThan (1-866-753-7784) >>> www.PLessThan.com >>> >>> ______________________________________________ >>> R-help at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-help >>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html >>> and provide commented, minimal, self-contained, reproducible code. >
On 11-04-2013, at 20:34, Fisher Dennis <fisher at plessthan.com> wrote:> Colleagues > > During the transition to R3.0.0 (OS X), one of the packages that I used -- SASxport -- did not work until I used the "type=source" option in install.packages. >See below. There is a binary version available.> This led to an adventure: > 1. I downloaded the package source: SASxport_1.2.4.tar.gz > 2. in the SASxport/R folder, I found all the functions that are part of the package. > I became interested in whether I could "source" these functions directly into R and re-create the functionality of the package without installing/"require"ing the package. > > This started with some success until I encountered one problem that I could not overcome. > When I executed the function write.xport, I received the following error message: > Error in .C("fill_file_header", cDate = xport.dateFMT(cDate), mDate = xport.dateFMT(mDate), : > C symbol name "fill_file_header" not in load table > > This appears to be coming from the following line of code in write.xport: > out(xport.file.header( cDate = cDate, sasVer = sasVer, osType = osType)) > The problem appears to be in > xport.file.header > for which the entire code is: > > xport.file.header <- > function(cDate=Sys.time(), mDate=cDate, sasVer="7.00", osType="Unknown" ) > { > .C("fill_file_header", > cDate = xport.dateFMT(cDate), # Creation date > mDate = xport.dateFMT(mDate), # Modification date > sasVer = toupper(as.character(sasVer)), # SAS version number > osType = as.character(osType) # Operating System (can include lowercase) > ) > > .Call("getRawBuffer", PACKAGE="SASxport") > > } > > Of note, I commented out the line: > .Call("getRawBuffer", PACKAGE="SASxport") > and the same error occurred (I did not expect this is solve the problem). > > I then looked in SASxport/src and found three files (which appear to be coded in C): > init.c > writeSAS.c > writeSAS.h > that refer to "fill_file_header" > > I suspect that these files need to be accessed in some manner in order for xport.file.header and other functions to work correctly. > The question is how do I access these files: > Do I "source" them in some manner? > Put them in a particular location where they are sourced automatically? > I tried dyn.load but that does not appear to be the correct approach. >These files are part of the package; packages have a strict organization of files. The files you are referring to are C files and need to be compiled. And that implies you will need to get hold of the appropriate compiler tools.> Any help would be greatly appreciated. >The exercise is quite futile. You really need to read the Writing R Extensions manual. There is a binary version of this package available on CRAN, which you can install using R.app. So you don't need to do what you are doing. Berend
On Apr 11, 2013, at 1:34 PM, Fisher Dennis <fisher at plessthan.com> wrote:> Colleagues > > During the transition to R3.0.0 (OS X), one of the packages that I used -- SASxport -- did not work until I used the "type=source" option in install.packages. > > This led to an adventure: > 1. I downloaded the package source: SASxport_1.2.4.tar.gz > 2. in the SASxport/R folder, I found all the functions that are part of the package. > I became interested in whether I could "source" these functions directly into R and re-create the functionality of the package without installing/"require"ing the package. > > This started with some success until I encountered one problem that I could not overcome. > When I executed the function write.xport, I received the following error message: > Error in .C("fill_file_header", cDate = xport.dateFMT(cDate), mDate = xport.dateFMT(mDate), : > C symbol name "fill_file_header" not in load table > > This appears to be coming from the following line of code in write.xport: > out(xport.file.header( cDate = cDate, sasVer = sasVer, osType = osType)) > The problem appears to be in > xport.file.header > for which the entire code is: > > xport.file.header <- > function(cDate=Sys.time(), mDate=cDate, sasVer="7.00", osType="Unknown" ) > { > .C("fill_file_header", > cDate = xport.dateFMT(cDate), # Creation date > mDate = xport.dateFMT(mDate), # Modification date > sasVer = toupper(as.character(sasVer)), # SAS version number > osType = as.character(osType) # Operating System (can include lowercase) > ) > > .Call("getRawBuffer", PACKAGE="SASxport") > > } > > Of note, I commented out the line: > .Call("getRawBuffer", PACKAGE="SASxport") > and the same error occurred (I did not expect this is solve the problem). > > I then looked in SASxport/src and found three files (which appear to be coded in C): > init.c > writeSAS.c > writeSAS.h > that refer to "fill_file_header" > > I suspect that these files need to be accessed in some manner in order for xport.file.header and other functions to work correctly. > The question is how do I access these files: > Do I "source" them in some manner? > Put them in a particular location where they are sourced automatically? > I tried dyn.load but that does not appear to be the correct approach. > > Any help would be greatly appreciated. > > Thanks > > DennisDennis, Based upon a review of the messages for the package on CRAN: http://cran.r-project.org/web/checks/check_results_SASxport.html there are a number of issues with the package, including calls to deprecated/obsolete functions and some issues with the C code. That all being said, the package does appear to have binaries available for Windows and OSX for R 3.0.0. What error(s) are you getting when you try to install the binary version of the package? If you are going to use the source version of the package, you will need to have a C compiler on your system in order to compile the package from source before it can be installed. However, compiling from source will not resolve the aforementioned issues. That will require a package update by Greg, the package maintainer. The package itself does not appear to have been updated since late 2010, so a communication with Greg would seem to be in order. I would reasonably presume, from my own experience, that Greg was contacted about these issues by one or more of the CRAN maintainers prior to the release of R 3.0.0., which would suggest that, as has happened in the past, Greg has gone missing. Regards, Marc