[Rd] AIX linking
We had four years ago http://tolstoy.newcastle.edu.au/R/devel/02a/0440.html It looks as if the export files are not required if runtime linking is used, e.g. http://www.ethereal.com/lists/ethereal-dev/21/msg00027.html suggests -bexpall -bnoentry suffices. This suggests that we should be linking the main R.bin executable with ld -brtl -bexpall -bnoentry rather than configure's ld -bdynamic -bM:SRE -bE$(top_builddir)/etc/R.exp and linking dynamic libraries such as libRlapack.so with ld -G -bexpall -bnoentry (If used from gcc, escape all these with -Wl, ) Does anyone know for sure? We really need some help from the AIX community to resolve these long-standing issues. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] data() statement in functions
Hi
I am writing a package in which a function needs a dataset (of
precomputed Stirling
numbers) to work. The .rda file resides in the data/ directory.
Toy example follows:
f <- function(x){
data(logS1)
. . . do stuff . . .
return(answer)
}
Is this a good way to do this?
What is best practice in such situations?
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data() statement in functions
On Wed, 2 Aug 2006, Robin Hankin wrote:
> Hi
>
> I am writing a package in which a function needs a dataset (of
> precomputed Stirling
> numbers) to work. The .rda file resides in the data/ directory.
>
> Toy example follows:
>
>
> f <- function(x){
>data(logS1)
>. . . do stuff . . .
>return(answer)
> }
>
>
> Is this a good way to do this?
> What is best practice in such situations?
This is exactly what the sysdata.rda facility is provided for: see
`Writing R Extensions'. (It works best for packages with namespaces, as
then its content is by default not exported.)
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] allocating character string of given size for .C
Hi, I have a C function (called via .C) which returns (by writing into buffers) some values of known (or fixed) length, all of these are numerical so I can allocate storage for them via as.double() and as.integer(). However, there is a potential error message that I would like to return into a char * buffer [1]. How can I allocate it in R (eg something similar to as.integer(), but taking the number of characters). I would like to avoid .Call if possible, this is the only tricky argument. Thanks, Tamas [1] I would of course use strncpy to avoid overflows. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] allocating character string of given size for .C
On Wed, 2 Aug 2006, Tamas K Papp wrote: > Hi, > > I have a C function (called via .C) which returns (by writing into > buffers) some values of known (or fixed) length, all of these are > numerical so I can allocate storage for them via as.double() and > as.integer(). > > However, there is a potential error message that I would like to > return into a char * buffer [1]. How can I allocate it in R (eg > something similar to as.integer(), but taking the number of > characters). It's a long time since I have done that, but AFAIR in S you needed to pass a length-one character vector containing a string of the appropriate maximal length. In R it is a little simpler: you are given a char** pointer p, and when returning from C, .C() copies the valued pointed to by p[i] to the ith element of a character vector via mkChar. So you need to pass a length-one character vector with anything in the first element, e.g. character(1). > I would like to avoid .Call if possible, this is the only tricky > argument. > > Thanks, > > Tamas > > [1] I would of course use strncpy to avoid overflows. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building windows packages under wine/linux and cross-compiling.
Hin-Tak Leung wrote:
> Prof Brian Ripley wrote:
>> On Mon, 31 Jul 2006, Hin-Tak Leung wrote:
>>
>>> Had some fun today, and thought it might be a good idea to share
>>> and possibly for inclusion to R/src/gnuwin32/README.packages .
>>
>>
>> Edit MkRules to set BUILD=CROSS and the appropriate paths (including
>> HEADER) as needed.
>
> On a different note, I am rather uncomfortable doing *both*
> makefile editing and setting options on the comand lines
> "make option1=value1 option2=vaule2 ...". Surely it is possible
> to do it entirely one way, e.g.
>
> make CROSS_ON_LINUX=1
After setting PATH=/mingw/bin, *without editing MkRules at all*,
this does work (note "BUILD=CROSS"):
make BUILD=CROSS R_EXE=/usr/bin/R PKGDIR=/home/hin-tak/tmp-cvs \
RLIB=/tmp pkg-snpMatrix
Apparently any variables ("BUILD" being one) specified on the make
command line overrides what's in the make file. Thus there is no need
to edit MkRules at all - HEADER can be specified in the same way
if needed (although it doesn't seem needed).
I'd prefer to do it this way - don't want to keep a locally
modified MkRules in my hard disc which differs from as-distributed
or as-installed (under wine).
There is a slight caveate - wine (and so does windows) installs
R under C:\Program Files\R\R- , and cross-build doesn't like
the space in "Program Files". (native build seems to be able to address
that as c://progr~1/...). Instead of taking it off and reinstall,
I opted for sshfs-fuse mounting my ".wine/drive_c/Program Files/R"
elsewhere without a space in the path.
HTL
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] C Entry Points
Thanks in advance for any suggestions:
I found this question asked on the forum a few times, but never found an
answer to the thread.
I'm getting this error when I try to call my c routine from R:
Error in .C("fifrt", as.double(x), ans = double(1), PACKAGE = "myPackage") :
C entry point "fifrt" not in DLL for package "myPackage"
Here's some basics about the system:
OS: RHEL v3 AS (Red Hat Enterprise Linux Advanced Server release 3)
Taroon Update 7
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)
--
View this message in context:
http://www.nabble.com/C-Entry-Points-tf2040772.html#a5617023
Sent from the R devel forum at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] allocating character string of given size for .C
On 8/2/2006 11:08 AM, Tamas K Papp wrote: > Hi, > > I have a C function (called via .C) which returns (by writing into > buffers) some values of known (or fixed) length, all of these are > numerical so I can allocate storage for them via as.double() and > as.integer(). > > However, there is a potential error message that I would like to > return into a char * buffer [1]. How can I allocate it in R (eg > something similar to as.integer(), but taking the number of > characters). > > I would like to avoid .Call if possible, this is the only tricky > argument. > > Thanks, > > Tamas > > [1] I would of course use strncpy to avoid overflows. If you are unsure of the length of the message that you want to return, you can use R_alloc in C to allocate a buffer, and you don't need to worry about disposing of it: it will be garbage collected. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C Entry Points
On Wed, 2 Aug 2006, Qsabound wrote:
>
> Thanks in advance for any suggestions:
>
> I found this question asked on the forum a few times, but never found an
> answer to the thread.
>
> I'm getting this error when I try to call my c routine from R:
>
> Error in .C("fifrt", as.double(x), ans = double(1), PACKAGE = "myPackage") :
>C entry point "fifrt" not in DLL for package "myPackage"
>
> Here's some basics about the system:
>
> OS: RHEL v3 AS (Red Hat Enterprise Linux Advanced Server release 3)
> Taroon Update 7
>
> gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-54)
Ok. So R doesn't think "fifrt" is in the package shared library and you
think it should be.
If you go to the myPackage/libs/ directory under the R library directory
you should find a file myPackage.so. Try
nm myPackage.so | grep fifrt
to list all the symbols containing "fifrt". It should now be clear
whether fifrt is there. This will narrow down the problem.
-thomas
> --
> View this message in context:
> http://www.nabble.com/C-Entry-Points-tf2040772.html#a5617023
> Sent from the R devel forum at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C Entry Points
Thanks for the help Thomas: Here's my output. I'll do some reading to determine what this implies.. nm myPackage.so | grep fifrt 06e4 T fifrt Thanks again -- View this message in context: http://www.nabble.com/C-Entry-Points-tf2040772.html#a5618043 Sent from the R devel forum at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building windows packages under wine/linux and cross-compiling.
Prof Brian Ripley wrote:
> This is make-specific. It is true for GNU make, but not for BSD-like
> makes (and you can also cross-compile from FreeBSD and Solaris x86).
I know it is very possibly GNU make specific -
but that section in R/src/gnuwin32/README.package specifically says
"Cross-building packages on Linux", so that section could benefit
with a bit of updating.
(plus mentioning that cross-compile from FreeBSD and Solaris x86 is
also possible - although there would be a few more loops to jump
though, not having convenient ready-made cross-gcc binaries).
Not modifying as-distributed or as-installed files is quite
an important point... besides wine, I can imagine somebody using
a proper windows partition via dual boot or via network'ed smbmount
for doing cross-compile's.
HTL
> On Wed, 2 Aug 2006, Hin-Tak Leung wrote:
>
>> Hin-Tak Leung wrote:
>>> Prof Brian Ripley wrote:
On Mon, 31 Jul 2006, Hin-Tak Leung wrote:
> Had some fun today, and thought it might be a good idea to share
> and possibly for inclusion to R/src/gnuwin32/README.packages .
>>
Edit MkRules to set BUILD=CROSS and the appropriate paths (including
HEADER) as needed.
>>
>>> On a different note, I am rather uncomfortable doing *both*
>>> makefile editing and setting options on the comand lines
>>> "make option1=value1 option2=vaule2 ...". Surely it is possible
>>> to do it entirely one way, e.g.
>>>
>>> make CROSS_ON_LINUX=1
>>
>>
>> After setting PATH=/mingw/bin, *without editing MkRules at all*,
>> this does work (note "BUILD=CROSS"):
>>
>>make BUILD=CROSS R_EXE=/usr/bin/R PKGDIR=/home/hin-tak/tmp-cvs \
>> RLIB=/tmp pkg-snpMatrix
>>
>> Apparently any variables ("BUILD" being one) specified on the make
>> command line overrides what's in the make file. Thus there is no need
>> to edit MkRules at all - HEADER can be specified in the same way
>> if needed (although it doesn't seem needed).
>>
>> I'd prefer to do it this way - don't want to keep a locally
>> modified MkRules in my hard disc which differs from as-distributed
>> or as-installed (under wine).
>>
>> There is a slight caveate - wine (and so does windows) installs
>> R under C:\Program Files\R\R- , and cross-build doesn't like
>> the space in "Program Files". (native build seems to be able to address
>> that as c://progr~1/...). Instead of taking it off and reinstall,
>> I opted for sshfs-fuse mounting my ".wine/drive_c/Program Files/R"
>> elsewhere without a space in the path.
>>
>> HTL
>>
>> __
>> 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
[Rd] R-2.3.1 on AIX 5.3 installation.
Hello all, I am trying to build R on AIX 5.3 on p595 using the native complier (xlc_r/xlf_r)? Has anyone installed R-2.3.1 on AIX 5.3 using the native complier (xlc_r)? If so would you reply with which flags and options did to use? I followed the suggested flags in the documentation. > setenvOBJECT_MODE 64 > setenvCC /usr/vac/bin/xlc_r > setenvF77 /usr/bin/xlf_r > setenvCXX /usr/vacpp/bin/xlC_r > setenvLDFLAGS '-brtl' > setenvCFLAGS '-O -qstrict' > setenvFFLAGS '-O -qstrict' > setenvCXXFLAGS'-O -qstrict' > setenvMAKEgmake R 2.3.1:The build fails when I make. > gmake[3]: Entering directory `/ibm_global/R/build/R-2.3.1/src/main' > /usr/vac/bin/xlc_r -I../../src/extra/zlib -I../../src/extra/bzip2 - > I../../src/extra/pcre -I. -I../../src/include -I../../src/include - > I/usr/local/include -DHAVE_CONFIG_H -O -qstrict -c printutils.c - > o printutils.o > "printutils.c", line 582.7: 1506-1352 (S) "va_start" may not appear > in a function without a variable argument list. > "printutils.c", line 591.5: 1506-277 (S) Syntax error: possible > missing ';' or ','? > "printutils.c", line 605.1: 1506-276 (S) Syntax error: possible > missing 'while'? > "printutils.c", line 637.1: 1506-276 (S) Syntax error: possible > missing 'while'? > "printutils.c", line 639.25: 1506-045 (S) Undeclared identifier n. > "printutils.c", line 639.12: 1506-1332 (W) A function with return > type "void" may not return a value of type "int". > "printutils.c", line 642.1: 1506-276 (S) Syntax error: possible > missing 'while'? > "printutils.c", line 645.25: 1506-045 (S) Undeclared identifier w. > "printutils.c", line 648.1: 1506-276 (S) Syntax error: possible > missing 'while'? > "printutils.c", line 653.17: 1506-045 (S) Undeclared identifier cl. > "printutils.c", line 661.43: 1506-045 (S) Undeclared identifier j. > "printutils.c", line 665.1: 1506-276 (S) Syntax error: possible > missing 'while'? > "printutils.c", line 685.1: 1506-276 (S) Syntax error: possible > missing 'while'? > "printutils.c", line 702.1: 1506-276 (S) Syntax error: possible > missing 'while'? > "printutils.c", line 707.17: 1506-045 (S) Undeclared identifier rl. > "printutils.c", line 713.17: 1506-045 (S) Undeclared identifier rlabw. > "printutils.c", line 713.25: 1506-045 (S) Undeclared identifier > lbloff. > "printutils.c", line 711.31: 1506-045 (S) Undeclared identifier > lbloff. > "printutils.c", line 718.2: 1506-204 (S) Unexpected end of file. > gmake[3]: *** [printutils.o] Error 1 > gmake[3]: Leaving directory `/ibm_global/R/build/R-2.3.1/src/main' > gmake[2]: *** [R] Error 2 > gmake[2]: Leaving directory `/ibm_global/R/build/R-2.3.1/src/main' > gmake[1]: *** [R] Error 1 > gmake[1]: Leaving directory `/ibm_global/R/build/R-2.3.1/src' > gmake: *** [R] Error 1 latest R-patched: also fails. > /usr/vac/bin/xlc_r -I../../src/extra/zlib -I../../src/extra/bzip2 - > I../../src/extra/pcre -I. -I../../src/include -I../../src/include - > I/usr/local/include -DHAVE_CONFIG_H -O -qstrict -c connections.c - > o connections.o > "connections.c", line 2732.18: 1506-052 (S) Duplicate case label > for value 4. Labels must be unique. > "connections.c", line 2750.18: 1506-052 (S) Duplicate case label > for value 4. Labels must be unique. > "connections.c", line 2935.18: 1506-052 (S) Duplicate case label > for value 4. Labels must be unique. > "connections.c", line 2979.18: 1506-052 (S) Duplicate case label > for value 4. Labels must be unique. > gmake[3]: *** [connections.o] Error 1 > gmake[3]: Leaving directory `/ibm_global/R/build/R-patched/src/main' > gmake[2]: *** [R] Error 2 > gmake[2]: Leaving directory `/ibm_global/R/build/R-patched/src/main' > gmake[1]: *** [R] Error 1 > gmake[1]: Leaving directory `/ibm_global/R/build/R-patched/src' Thanks, Kamil Kamil Marcinkowski Westgrid System Administrator [EMAIL PROTECTED] University of Alberta site Tel.780 492-0354 Research Computing Support Fax.780 492-1729 Academic ICT Edmonton, Alberta, CANADAUniversity of Alberta "This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and/or privileged information. Please contact us immediately if you are not the intended recipient of this communication. If you are not the intended recipient of this communication, do not copy, distribute, or take action on it. Any communication received in error, or subsequent reply, should be deleted or destroyed." [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.3.1 on AIX 5.3 installation.
On Wed, 2 Aug 2006, kamil Marcinkowski wrote: > latest R-patched: also fails. > >> /usr/vac/bin/xlc_r -I../../src/extra/zlib -I../../src/extra/bzip2 - >> I../../src/extra/pcre -I. -I../../src/include -I../../src/include - >> I/usr/local/include -DHAVE_CONFIG_H -O -qstrict -c connections.c - >> o connections.o >> "connections.c", line 2732.18: 1506-052 (S) Duplicate case label >> for value 4. Labels must be unique. >> "connections.c", line 2750.18: 1506-052 (S) Duplicate case label >> for value 4. Labels must be unique. >> "connections.c", line 2935.18: 1506-052 (S) Duplicate case label >> for value 4. Labels must be unique. >> "connections.c", line 2979.18: 1506-052 (S) Duplicate case label >> for value 4. Labels must be unique. This looks as if sizeof short = sizeof int = 4, which is permitted by the C standard, but distinctly unusual. If so, you could delete or #ifdef out the case sizeof(short): lines to remove the duplication. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C Entry Points
On Aug 2, 2006, at 12:09 PM, Qsabound wrote:
>
> Thanks in advance for any suggestions:
>
> I found this question asked on the forum a few times, but never
> found an
> answer to the thread.
>
> I'm getting this error when I try to call my c routine from R:
>
> Error in .C("fifrt", as.double(x), ans = double(1), PACKAGE =
> "myPackage") :
> C entry point "fifrt" not in DLL for package "myPackage"
>
make sure you used dyn.load or library.dynam to load the .so - you
should have something like
.First.lib <- function(libname, pkgname) {
library.dynam("myPackage", pkgname, libname)
}
in your package (or use useDynLib if your package has a namespace).
If it still doesn't help, try it without the PACKAGE=.. argument and
load the .so manually using dyn.load
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building windows packages under wine/linux and cross-compiling.
Hin-Tak Leung wrote:
> Prof Brian Ripley wrote:
>
>>This is make-specific. It is true for GNU make, but not for BSD-like
>>makes (and you can also cross-compile from FreeBSD and Solaris x86).
>
>
> I know it is very possibly GNU make specific -
> but that section in R/src/gnuwin32/README.package specifically says
> "Cross-building packages on Linux", so that section could benefit
> with a bit of updating.
>
> (plus mentioning that cross-compile from FreeBSD and Solaris x86 is
> also possible - although there would be a few more loops to jump
> though, not having convenient ready-made cross-gcc binaries).
>
> Not modifying as-distributed or as-installed files is quite
> an important point... besides wine, I can imagine somebody using
> a proper windows partition via dual boot or via network'ed smbmount
> for doing cross-compile's.
I cannot imagine: Why should one want to perform difficult cross
compiling if you have Windows available?
And why should I run R under wine? If I like Windows, I use Windows, if
I have like Linux, there is no reason to run R under wine.
Uwe Ligges
>
> HTL
>
>
>>On Wed, 2 Aug 2006, Hin-Tak Leung wrote:
>>
>>
>>>Hin-Tak Leung wrote:
>>>
Prof Brian Ripley wrote:
>On Mon, 31 Jul 2006, Hin-Tak Leung wrote:
>
>
>>Had some fun today, and thought it might be a good idea to share
>>and possibly for inclusion to R/src/gnuwin32/README.packages .
>>>
>>>
>>>
> Edit MkRules to set BUILD=CROSS and the appropriate paths (including
> HEADER) as needed.
>>>
>>>
>>>
On a different note, I am rather uncomfortable doing *both*
makefile editing and setting options on the comand lines
"make option1=value1 option2=vaule2 ...". Surely it is possible
to do it entirely one way, e.g.
make CROSS_ON_LINUX=1
>>>
>>>
>>>
>>>After setting PATH=/mingw/bin, *without editing MkRules at all*,
>>>this does work (note "BUILD=CROSS"):
>>>
>>> make BUILD=CROSS R_EXE=/usr/bin/R PKGDIR=/home/hin-tak/tmp-cvs \
>>> RLIB=/tmp pkg-snpMatrix
>>>
>>>Apparently any variables ("BUILD" being one) specified on the make
>>>command line overrides what's in the make file. Thus there is no need
>>>to edit MkRules at all - HEADER can be specified in the same way
>>>if needed (although it doesn't seem needed).
>>>
>>>I'd prefer to do it this way - don't want to keep a locally
>>>modified MkRules in my hard disc which differs from as-distributed
>>>or as-installed (under wine).
>>>
>>>There is a slight caveate - wine (and so does windows) installs
>>>R under C:\Program Files\R\R- , and cross-build doesn't like
>>>the space in "Program Files". (native build seems to be able to address
>>>that as c://progr~1/...). Instead of taking it off and reinstall,
>>>I opted for sshfs-fuse mounting my ".wine/drive_c/Program Files/R"
>>>elsewhere without a space in the path.
>>>
>>>HTL
>>>
>>>__
>>>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] building windows packages under wine/linux and cross-compiling.
Uwe Ligges wrote: > > I cannot imagine: Why should one want to perform difficult cross > compiling if you have Windows available? > And why should I run R under wine? If I like Windows, I use Windows, if > I have like Linux, there is no reason to run R under wine. *You* cannot imagine. I am an almost exlusively linux person. An acquitance, also a mainly linux person, for teaching purpose, asked for windows binary of something I (co-)wrote, to be installed on to the teaching machines. Installing too many development tools on teaching machines is not an option; so the other option, than cross-compiling, is to *borrow* a windows machine *set up for development purposes*. (which I did, at the start). I cannot, and would not, keep on repeatedly borrowing other people's windows development machines, which they have possibly spent some time in setting up; besides, they may not have all the tools, and/or willing to put things like Mingw or ActiveState Perl on their machines. I did have to install both, plus the latest version of R - in my first native try, and immediately de-installing them from the borrowed machine as soon as I finished. You are not involved in any teaching roles, I reckon? And you haven't written any packages that you would like others to use, on a different platform from your own? Since I am cross-compiling, it goes that I would like to test the result of cross-compiling right-away under wine, without switching machine or rebooting (in case of dual boot). In fact I found and fix a bug in my code, which *only* shows up under wine's implementation of msvcrt, not on win2k's or glibc's - wine's msvcrt behavior is valid ANSI C, but different from MS win2k or linux glibc's. (and nobody can say for sure win2k's msvcrt is exactly the same as NT, XP, etc's). HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building windows packages under wine/linux and cross-compiling.
On 8/2/2006 6:05 PM, Hin-Tak Leung wrote: > Uwe Ligges wrote: > >> I cannot imagine: Why should one want to perform difficult cross >> compiling if you have Windows available? >> And why should I run R under wine? If I like Windows, I use Windows, if >> I have like Linux, there is no reason to run R under wine. > > *You* cannot imagine. > > I am an almost exlusively linux person. An acquitance, also a > mainly linux person, for teaching purpose, asked for windows binary > of something I (co-)wrote, to be installed on to the teaching machines. > Installing too many development tools on teaching machines is not > an option; so the other option, than cross-compiling, is to > *borrow* a windows machine *set up for development purposes*. > (which I did, at the start). > > I cannot, and would not, keep on repeatedly borrowing other > people's windows development machines, which they have possibly > spent some time in setting up; besides, they may not have all > the tools, and/or willing to put things like Mingw or ActiveState > Perl on their machines. I did have to install both, plus the > latest version of R - in my first native try, and immediately > de-installing them from the borrowed machine as soon as I finished. > > You are not involved in any teaching roles, I reckon? And you haven't > written any packages that you would like others to use, on a > different platform from your own? > > Since I am cross-compiling, it goes that I would like to test > the result of cross-compiling right-away under wine, without > switching machine or rebooting (in case of dual boot). In fact I > found and fix a bug in my code, which *only* shows up under > wine's implementation of msvcrt, not on win2k's or glibc's - wine's > msvcrt behavior is valid ANSI C, but different from MS win2k > or linux glibc's. (and nobody can say for sure win2k's msvcrt is > exactly the same as NT, XP, etc's). What I'd recommend you do is get an old laptop with Windows installed on it, and install the development tools there. There are probably several lying around peoples' offices in your department. If you found bugs in your code because of differences between wine and Windows, you're also bound to find bugs in wine, and waste a lot of time trying to see what's wrong with your code when really there's nothing at all wrong with it. You'll also soon find people complaining that your package doesn't contain compiled HTML help, because there's no Linux tool to build that. Windows machines are cheap. You don't need a new one to build a package or to run R. I can't imagine there is any change to the build procedure that would cost less in our time than the cost to you of getting an old Windows box. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building windows packages under wine/linux and cross-compiling.
Duncan Murdoch wrote: > On 8/2/2006 6:05 PM, Hin-Tak Leung wrote: > >>Uwe Ligges wrote: >> >> >>>I cannot imagine: Why should one want to perform difficult cross >>>compiling if you have Windows available? >>>And why should I run R under wine? If I like Windows, I use Windows, if >>>I have like Linux, there is no reason to run R under wine. >> >>*You* cannot imagine. >> >>I am an almost exlusively linux person. An acquitance, also a >>mainly linux person, for teaching purpose, asked for windows binary >>of something I (co-)wrote, to be installed on to the teaching machines. >>Installing too many development tools on teaching machines is not >>an option; so the other option, than cross-compiling, is to >>*borrow* a windows machine *set up for development purposes*. >>(which I did, at the start). >> >>I cannot, and would not, keep on repeatedly borrowing other >>people's windows development machines, which they have possibly >>spent some time in setting up; besides, they may not have all >>the tools, and/or willing to put things like Mingw or ActiveState >>Perl on their machines. I did have to install both, plus the >>latest version of R - in my first native try, and immediately >>de-installing them from the borrowed machine as soon as I finished. >> >>You are not involved in any teaching roles, I reckon? And you haven't >>written any packages that you would like others to use, on a >>different platform from your own? >> >>Since I am cross-compiling, it goes that I would like to test >>the result of cross-compiling right-away under wine, without >>switching machine or rebooting (in case of dual boot). In fact I >>found and fix a bug in my code, which *only* shows up under >>wine's implementation of msvcrt, not on win2k's or glibc's - wine's >>msvcrt behavior is valid ANSI C, but different from MS win2k >>or linux glibc's. (and nobody can say for sure win2k's msvcrt is >>exactly the same as NT, XP, etc's). > > > What I'd recommend you do is get an old laptop with Windows installed on > it, and install the development tools there. There are probably several > lying around peoples' offices in your department. If you found bugs in > your code because of differences between wine and Windows, you're also > bound to find bugs in wine, and waste a lot of time trying to see what's > wrong with your code when really there's nothing at all wrong with it. > > You'll also soon find people complaining that your package doesn't > contain compiled HTML help, because there's no Linux tool to build that. > > Windows machines are cheap. You don't need a new one to build a package > or to run R. I can't imagine there is any change to the build procedure > that would cost less in our time than the cost to you of getting an old > Windows box. Or dual-boot your existing linux machine...? Sean __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C Entry Points
Qsabound <[EMAIL PROTECTED]> writes:
> Thanks for the help Thomas:
>
> Here's my output. I'll do some reading to determine what this implies..
>
> nm myPackage.so | grep fifrt
> 06e4 T fifrt
That indicates that your fifrt function is in the shared library. I
suspect the issue you are seeing is related to the registration (or
lack) of native routines.
Try having a look at the Writing R Extensions manual:
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
After loading your package, use getLoadedDLLs() to verify that your
.so is actually getting loaded.
Then have a look at:
getDLLRegisteredRoutines("YOUR_PACKAGE")
To see what is getting registered.
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] C++ in an R package
Hi all, I've read the manual on implementing C++ in R but I must be tripping over something simple. I am just trying to run a simple "Hello World" program from R and I understand how to call the function andhave no problem getting the package to install and, but should I expect .so files in the package directory? I see the "build" command creates them in src but they don't appear in the src file once the library is installed. How do I point R to those files (in .First.lib?) in order to load them before using .C()? I'm sorry if this is clear to everyone else, I'm just struggling with it. Thanks so much, Selwyn-Lloyd McPherosn __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C++ in an R package
Oh, of course, a few minutes after asking, I think I've figured it out. :) But, out of curiosity, even if I have a C++ program "whatever.cpp" in /src, there is no "whatever" file in the installation directory; where is that information going? Thanks! Selwyn-Lloyd McPherson __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C++ in an R package
On Aug 2, 2006, at 11:04 PM, Selwyn-Lloyd McPherson wrote: > Oh, of course, a few minutes after asking, I think I've figured it > out. :) But, out of curiosity, even if I have a C++ program > "whatever.cpp" in /src, there is no "whatever" file in the > installation directory; where is that information going? A slightly dumbed down explanation: basically all that is stored in a single shared object located in "libs", called PACKAGENAME.SOMETHING, where SOMETHING is dependent on your OS. On Linux/Mac it is "so". If you have several source files, you still only get a single shared object file which contains everything from the different source files. Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
