Re: [Rd] C vs. C++ as learning and development tool for R

[Vladimir Dergachev]

On Friday 19 January 2007 6:46 pm, Ross Boylan wrote:
> On Fri, Jan 19, 2007 at 03:55:30AM -0500, Kimpel, Mark William wrote:
> I can't say much about "libraries already on other machines", but the
> C runtime is probably the one you can count on being there the most.

Well, I don't think it is there on Windows machines - and it is specific to 
the compiler. Visual C has several different versions, Borland had its own 
and there were several major releases of GNU C library.

My preference is that on Windows one only distributes static binaries, or, 
uses a small loadable object (i.e. dll) from Tcl/Tk or R.

On Linux I found it is best to link C and X11/GL libraries dynamically (as 
older versions are usually available) and link everything else statically. 
Major exception: condor linked binaries are static.

Caveat - I have not distributed anything but GPL/LGPL code, so making static 
binaries was not an issue. If you have a closed source application than any 
LGPL libraries you use must be linked dynamically and you cannot use GPL code 
at all.

   best

   Vladimir Dergachev

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Charles C. Berry]

On Sat, 20 Jan 2007, Roger Bivand wrote:

> On Fri, 19 Jan 2007, Kimpel, Mark William wrote:
>
>> Thanks to all for your excellent suggestions. I think will I proceed

[snip]


Commenting on writing R packages with portable C/C++ code:

>
> [F]ollowing the guides to the letter gets you there like
> marked stones across a marsh. Leaving the path usually gets you at best
> neck deep in the mire, alternatively just bubbles.

Fortune!

[snip]


Charles C. Berry(858) 534-2098
  Dept of Family/Preventive Medicine
E mailto:[EMAIL PROTECTED]   UC San Diego
http://biostat.ucsd.edu/~cberry/ La Jolla, San Diego 92093-0901

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Roger Bivand]

On Fri, 19 Jan 2007, Kimpel, Mark William wrote:

> Thanks to all for your excellent suggestions. I think will I proceed
> working through the Stroustrup book. He has a section on comparing C
> with C++ and one on working with legacy C code that may prove helpful. I
> also have a "C for Dummies" (something like that, I don't have it right
> next to me) that I have also been reading. A couple of follow-up
> questions:

C with data abstraction (C with Classes) is where C++ came from (that is a 
hybrid of Simula and C). Clean C is very portable, whereas C++ can get 
caught by name mangling between compiler versions. Arguably (certainly in 
cost and probably in elegance) a good deal can still be harvested from 
another young adult (20+ might be seen as IT archeology by some?) - SICP 
is online at:

http://mitpress.mit.edu/sicp/full-text/book/book.html

and is excellent on programming in general, just Chapter 1 is refreshing
to (re)read every now and then. Kernighan and Pike's "The Practice of
Programming" - simplicity, clarity, generality - is also good for one's
common sense. 


> 
> 1. As I understand it, if I just wanted to distribute compiled code, I
> could use whatever extended C or C++ libraries that I wanted to use,
> however, since R is open source and people need to be able to compile
> things themselves, I imagine I would get into trouble (figuratively)
> using, say, the C++ STL. Would I need to distribute these files as well?
> For example, iostream instead of stdio.h. Or, should I just not use
> those?

Very few things are as standardised as they claim. I/O should not be done 
other than through R (like memory management where possible), so reducing 
the number of things that can go wrong (on some platform).

> 
> 2. For those of you who develop C on Windows (probably a small bunch!),
> what is your preferred development environment? I have the free Borland
> Turbo C++ and Visual C++ 6.0 (I knew enough to stay away from .NET). I
> tried to install the C++ module for Eclipse and, for me at least, it was
> a nightmare. I am not UNIX or DOS savvy and setting path variables and
> the like just made things too complicated.

Just MinGW like R, following the guides to the letter gets you there like
marked stones across a marsh. Leaving the path usually gets you at best
neck deep in the mire, alternatively just bubbles. The existing code in
both base R and the contributed packages is a good guide, but prototyping
in R alone, and profiling to see where things take time before
implementing in a compiled language, is often prudent.

> 
> 3. Lastly, is there a C or C++ community similar to R that I could
> address questions relating to those languages to? I don't want to abuse
> the R list as I learn.
> 
> Thanks,
> Mark
> 
> Mark W. Kimpel MD 
> 
>  
> 
> (317) 490-5129 Work, & Mobile
> 
>  
> 
> (317) 663-0513 Home (no voice mail please)
> 
> 1-(317)-536-2730 FAX
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Ross Boylan]

On Fri, Jan 19, 2007 at 03:55:30AM -0500, Kimpel, Mark William wrote:
> I have 3 years of experience with R and have an interest in becoming a
> better programmer so that I might someday be able to contribute
> packages. Other than R, my only experience was taking Lisp from Daniel
> Friedman in the 1970's. I would like to learn either C or C++ for
> several reasons:
> 
> To gain a better concept of object oriented programming so that I can
> begin to use S4 methods in R.
> 
> To perhaps speed up some things I do repeatedly in R
> 
> To be able to contribute a package someday.
> 
>  
> 
> I have been doing some reading and from what I can tell R is more
> compatible with C, but C++ has much greater capabilities for OO
> programming.
> 
>  
> 
> I have just started reading The C++ Programming Language: Special
> Edition by Bjarne Stroustrup
>  ustrup&z=y> , he recommends first learning C++ and then then C if
> necessary, but as a developer of C++, he is probably biased.
> 
>  
> 
> I would greatly appreciate the advice of the R developers and package
> contributors on this subject. "C" or "C++"?
> 

To echo several other comments, if your goal is to work in R, it would
be best to go straight to R.  I haven't used lisp much, but I believe
it is much closer to R than most other languages you could pick.  It
has a functional style, and I recall reading the R's scoping rules
were directly inspired by Scheme, a Lisp variant.  In fact, I didn't
feel I fully grasped them until I looked at Abelson and Sussman's
"Structure and Interpretation of Computer Languages" (which uses
Scheme).

The "functional" OO of R is significantly different from the
"class-based" OO found in most languages calling themselves object
oriented, including C++, Java, Python and smalltalk.  Learning those
other languages to understand R could actually interfere with learning
R.

If and when you need speed, you can program in any language that
supports Fortran or C interfaces, which is almost all of them.

If you're just doing general education

I use C++ in R, and I have to say that programming in C++ is a
wretched experience.  You have to make a major committment to learning
the language, which is a minefield of gotcha's, to use it in full OO
style.  As others on this list and Stroustrup suggest, you can use it
and just incrementally add features over what you would do in C.  It
can also be speedy and powerful (to run, not to program in!), which is
why I'm using it.

For pure OO, I think you can't beat smalltalk, which is freely
available at www.squeak.org (also there is a GNU and several
commerical versions).  The language rules and syntax fit on one page.
The catch is that to use it you need to learn the environment and the
class library; these too are big tasks.

Objective-C is a much more lightweight C'ish OO than C++ (the author
moved smalltalk concepts into C).  It's available as part of the GNU
compilers.  Unlike smalltalk, you might use it if you cared about
performance, and it's the native language of Mac OS-X.  It has a
relatively small learning curve.

Python and Java are other choices for OO, both significantly simpler
than C++.  I find Python to be simple and elegant; it's also nifty for
scripting random tasks.  Java's widely used on the web and in the
enterprise.  Eiffel is also interesting.

I can't say much about "libraries already on other machines", but the
C runtime is probably the one you can count on being there the most.

Of course, another route would be to explore other functional
languages, a terrain I barely know: Haskell, ML, OCaml...  In
particular, some of them have lazy evaluation of arguments, which R
also employs.  And there are the functional/object languages like CLOS
(I think the O in OCaml is Object).

Anyway, this risks becoming a general language thread.  My main point,
as someone who's been there, is don't use C++ unless you have a
compelling reason and a lot of time!

Ross Boylan

(Among the languages listed, the ones I've used extensively are C,
C++, Objective-C, Python, R, and smalltalk.)

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

Re: [Rd] Cross-compile errors under R-2.4.0 and R-2.4.1

[Hin-Tak Leung]

Simon Urbanek wrote:

> 
> In fact, there is even one more caveat which I don't remember seeing 
> mentioned - it *must* be a build without r_arch set, otherwise the 
> cross-build fails as well (despite a correct version). I got bitten by 
> this recently when trying to use the OS X binary for cross-building..

I developed my own multi-arch set up during 2.3.x before the official
implementation - I have a "massaged" rpm spec file which, depends on
whether one does 'rpmbuild --target=i686 R.spec' or just 'rpmbuild 
R.spec' (='rpmbuild --target=x86_64 R.spec'), prepend -m32 to 
CFLAGS/FFLAGS/LDFLAGS, switch %_lib between lib or lib64, and also
rename /usr/bin/R to /usr/bin/R64 . So my 32-bit R and 64-bit R are 
essentially separate: /usr/bin/R + /usr/lib/R for 32-bit, /usr/bin/R64
+ /usr/lib64/R for 64-bit, and they only share the docs directories
such as /usr/share/info and /usr/share/doc/R-* . I read that the new 
r_arch based set-up is more space efficient, but I haven't switch
over yet (and not in any great urgency, since my current bi-arch
set up does what I want).

> And while we are at cross-building, it is possible to generate chm 
> manuals via hhc through wine, but you have to use original itss.dll 
> instead of the one supplied by wine. The hhw path in MkRules must then 
> point to the local directory on the host (because it's used for the 
> headers files) and you'll have to create shell-wrapper for hhc that 
> looks somewhat like "wine hhc.exe $*".

Thanks for that tip - I'll be sure to try it out the next time I 
cross-build. Are you using wine under OS X intel or did we switch
platform in two paragraphs? Just for curiosity.

Hin-Tak

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Duncan Murdoch]

On 1/19/2007 10:04 AM, Kimpel, Mark William wrote:
> Thanks to all for your excellent suggestions. I think will I proceed
> working through the Stroustrup book. He has a section on comparing C
> with C++ and one on working with legacy C code that may prove helpful. I
> also have a "C for Dummies" (something like that, I don't have it right
> next to me) that I have also been reading. A couple of follow-up
> questions:
> 
> 1. As I understand it, if I just wanted to distribute compiled code, I
> could use whatever extended C or C++ libraries that I wanted to use,
> however, since R is open source and people need to be able to compile
> things themselves, I imagine I would get into trouble (figuratively)
> using, say, the C++ STL. Would I need to distribute these files as well?
> For example, iostream instead of stdio.h. Or, should I just not use
> those?

The STL is available on most platforms, as far as I know.  Some more 
specialized libraries (e.g. GSL, database access, OpenGL) are more trouble.

If you want to use the more specialized ones, I'd try compiling your 
package using the standard build tools on one or two platforms, and see 
what happens.
> 
> 2. For those of you who develop C on Windows (probably a small bunch!),
> what is your preferred development environment? I have the free Borland
> Turbo C++ and Visual C++ 6.0 (I knew enough to stay away from .NET). I
> tried to install the C++ module for Eclipse and, for me at least, it was
> a nightmare. I am not UNIX or DOS savvy and setting path variables and
> the like just made things too complicated.

R uses the MinGW gcc compiler on Windows, so you need to have it 
available to build your packages when you get to that, but it doesn't 
have a nice IDE like those others.  Some purists hate IDEs, but I think 
they are very helpful.  I've never used Turbo C++ and rarely used 
MSVC++, so I can't really recommend one over the other, but I did like 
the Borland IDE for Pascal/Delphi.

Duncan Murdoch

> 3. Lastly, is there a C or C++ community similar to R that I could
> address questions relating to those languages to? I don't want to abuse
> the R list as I learn.
> 
> Thanks,
> Mark
> 
> Mark W. Kimpel MD 
> 
>  
> 
> (317) 490-5129 Work, & Mobile
> 
>  
> 
> (317) 663-0513 Home (no voice mail please)
> 
> 1-(317)-536-2730 FAX
> 
> __
> 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] C vs. C++ as learning and development tool for R

[Kimpel, Mark William]

Thanks to all for your excellent suggestions. I think will I proceed
working through the Stroustrup book. He has a section on comparing C
with C++ and one on working with legacy C code that may prove helpful. I
also have a "C for Dummies" (something like that, I don't have it right
next to me) that I have also been reading. A couple of follow-up
questions:

1. As I understand it, if I just wanted to distribute compiled code, I
could use whatever extended C or C++ libraries that I wanted to use,
however, since R is open source and people need to be able to compile
things themselves, I imagine I would get into trouble (figuratively)
using, say, the C++ STL. Would I need to distribute these files as well?
For example, iostream instead of stdio.h. Or, should I just not use
those?

2. For those of you who develop C on Windows (probably a small bunch!),
what is your preferred development environment? I have the free Borland
Turbo C++ and Visual C++ 6.0 (I knew enough to stay away from .NET). I
tried to install the C++ module for Eclipse and, for me at least, it was
a nightmare. I am not UNIX or DOS savvy and setting path variables and
the like just made things too complicated.

3. Lastly, is there a C or C++ community similar to R that I could
address questions relating to those languages to? I don't want to abuse
the R list as I learn.

Thanks,
Mark

Mark W. Kimpel MD 

 

(317) 490-5129 Work, & Mobile

 

(317) 663-0513 Home (no voice mail please)

1-(317)-536-2730 FAX

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

Re: [Rd] Cross-compile errors under R-2.4.0 and R-2.4.1

[Simon Urbanek]

On Jan 19, 2007, at 2:38 PM, Hin-Tak Leung wrote:

> Prof Brian Ripley wrote:
>> The 2.4.0 issue has been well documented only last week, in the  
>> thread
>>
>> https://stat.ethz.ch/pipermail/r-help/2007-January/123303.html
>>
>> as well as in an answer I had already posted.
>>
>> I am almost certain the issue for 2.4.1 is user error.  Remember  
>> you need
>> to set in MkRules
>>
>> ## === cross-compilation settings  =
>>
>> ...
>>
>> # path (possibly full path) to same version of R on the host system
>> # R_EXE=R
>>
>> R 2.4.1 does have seq_along, so it must not be the same version.
>
> I feel that one point in the cross-build related documentation  
> wasn't emphasized enough, and may have caused this sort of error  
> when one tries to build multiple versions of R: the version of  
> native R used *must* match the version of cross R one intends to  
> build.
>

In fact, there is even one more caveat which I don't remember seeing  
mentioned - it *must* be a build without r_arch set, otherwise the  
cross-build fails as well (despite a correct version). I got bitten  
by this recently when trying to use the OS X binary for cross-building..

And while we are at cross-building, it is possible to generate chm  
manuals via hhc through wine, but you have to use original itss.dll  
instead of the one supplied by wine. The hhw path in MkRules must  
then point to the local directory on the host (because it's used for  
the headers files) and you'll have to create shell-wrapper for hhc  
that looks somewhat like "wine hhc.exe $*".

Cheers,
Simon

>
>> On Fri, 19 Jan 2007, Daniel Berg wrote:
>>
>>> Dear all,
>>>
>>> I already posted a question regarding this to an existing thread:
>>> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
>>>
>>> I apologize for the double posting but I have some further  
>>> information
>>> that might be illuminating.
>>>
>>> I am trying to cross-compile my R-package under ubuntu linux, kernel
>>> 2.6.17-10-generic, on an IBM T60.
>>>
>>> I am following the suggested steps in
>>> http://cran.r-project.org/doc/contrib/cross-build.pdf
>>>
>>> I have tried changing R = R-x.x.x (2.3.1, 2.4.0 and 2.4.1) in
>>> http://cran.ii.uib.no/doc/contrib/Makefile-rcb
>>>
>>> 1) For R-2.3.1 everything works fine
>>> 2) For R-2.4.0 I receive the following error messages from 'make R':
>>>
>>> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text 
>>> +0x1f2a):
>>> more undefined references to `__pcre_ucp_findprop' follow
>>> collect2: ld returned 1 exit status
>>> make[4]: *** [R.dll] Error 1
>>> make[3]: *** [../../bin/R.dll] Error 2
>>> make[2]: *** [rbuild] Error 2
>>> make[1]: *** [all] Error 2
>>> make[1]: Leaving directory
>>>
>>> There is already a post that seems to address the same error:
>>> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
>>>
>>> However, I have tried the suggestions there with no further success
>>> and I am awaiting further instructions before pursuing that  
>>> solution.
>>>
>>> 3) For R-2.4.1 I receive the following error message from 'make R',
>>> under 'Making package tools':
>>>
>>> preparing package tools for lazy loading
>>> Error in makeLazyLoadDB(ns, dbbase) : could not find function  
>>> "seq_along"
>>> Execution halted
>>>
>>>
>>> Hope this is illuminating and that the 'bugs', whether it is in R or
>>> in PCRE, can be resolved for the next release, this would be highly
>>> appreciated. Meanwhile, any suggestions as to how I can cross- 
>>> compile
>>> successfully under R-2.4.1 are most welcome.
>>>
>>> Best wishes,
>>> Daniel Berg
>>>
>>
>
> __
> 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] Cross-compile errors under R-2.4.0 and R-2.4.1

[Daniel Berg]

Thank you so much for your great answers, and I apologize for using
obsolete versions and not being up to date on all the posts.

My native linux R is indeed R-2.3.1 which was also the version for
which I successfully cross-compiled. When trying to cross-compile for
2.4.0 and 2.4.1 I was not successful.

//Daniel

On 1/19/07, Hin-Tak Leung <[EMAIL PROTECTED]> wrote:
> Prof Brian Ripley wrote:
> > The 2.4.0 issue has been well documented only last week, in the thread
> >
> > https://stat.ethz.ch/pipermail/r-help/2007-January/123303.html
> >
> > as well as in an answer I had already posted.
> >
> > I am almost certain the issue for 2.4.1 is user error.  Remember you need
> > to set in MkRules
> >
> > ## === cross-compilation settings  =
> >
> > ...
> >
> > # path (possibly full path) to same version of R on the host system
> > # R_EXE=R
> >
> > R 2.4.1 does have seq_along, so it must not be the same version.
>
> I feel that one point in the cross-build related documentation
> wasn't emphasized enough, and may have caused this sort of error
> when one tries to build multiple versions of R: the version of
> native R used *must* match the version of cross R one intends to build.
>
> The user mentioned that he tried building R 2.3.1, 2.4.0 and 2.4.1 ;
> the only way it would work successfully would be that he also has
> linux native R of all three of those versions.
>
> HTL
>
> > On Fri, 19 Jan 2007, Daniel Berg wrote:
> >
> >> Dear all,
> >>
> >> I already posted a question regarding this to an existing thread:
> >> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
> >>
> >> I apologize for the double posting but I have some further information
> >> that might be illuminating.
> >>
> >> I am trying to cross-compile my R-package under ubuntu linux, kernel
> >> 2.6.17-10-generic, on an IBM T60.
> >>
> >> I am following the suggested steps in
> >> http://cran.r-project.org/doc/contrib/cross-build.pdf
> >>
> >> I have tried changing R = R-x.x.x (2.3.1, 2.4.0 and 2.4.1) in
> >> http://cran.ii.uib.no/doc/contrib/Makefile-rcb
> >>
> >> 1) For R-2.3.1 everything works fine
> >> 2) For R-2.4.0 I receive the following error messages from 'make R':
> >>
> >> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
> >> more undefined references to `__pcre_ucp_findprop' follow
> >> collect2: ld returned 1 exit status
> >> make[4]: *** [R.dll] Error 1
> >> make[3]: *** [../../bin/R.dll] Error 2
> >> make[2]: *** [rbuild] Error 2
> >> make[1]: *** [all] Error 2
> >> make[1]: Leaving directory
> >>
> >> There is already a post that seems to address the same error:
> >> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
> >>
> >> However, I have tried the suggestions there with no further success
> >> and I am awaiting further instructions before pursuing that solution.
> >>
> >> 3) For R-2.4.1 I receive the following error message from 'make R',
> >> under 'Making package tools':
> >>
> >> preparing package tools for lazy loading
> >> Error in makeLazyLoadDB(ns, dbbase) : could not find function "seq_along"
> >> Execution halted
> >>
> >>
> >> Hope this is illuminating and that the 'bugs', whether it is in R or
> >> in PCRE, can be resolved for the next release, this would be highly
> >> appreciated. Meanwhile, any suggestions as to how I can cross-compile
> >> successfully under R-2.4.1 are most welcome.
> >>
> >> Best wishes,
> >> Daniel Berg
> >>
> >
>
>
>


-- 
danielberg.no

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

Re: [Rd] Cross-compile errors under R-2.4.0 and R-2.4.1

[Hin-Tak Leung]

Prof Brian Ripley wrote:
> The 2.4.0 issue has been well documented only last week, in the thread
> 
> https://stat.ethz.ch/pipermail/r-help/2007-January/123303.html
> 
> as well as in an answer I had already posted.
> 
> I am almost certain the issue for 2.4.1 is user error.  Remember you need 
> to set in MkRules
> 
> ## === cross-compilation settings  =
> 
> ...
> 
> # path (possibly full path) to same version of R on the host system
> # R_EXE=R
> 
> R 2.4.1 does have seq_along, so it must not be the same version.

I feel that one point in the cross-build related documentation
wasn't emphasized enough, and may have caused this sort of error
when one tries to build multiple versions of R: the version of
native R used *must* match the version of cross R one intends to build.

The user mentioned that he tried building R 2.3.1, 2.4.0 and 2.4.1 ;
the only way it would work successfully would be that he also has
linux native R of all three of those versions.

HTL

> On Fri, 19 Jan 2007, Daniel Berg wrote:
> 
>> Dear all,
>>
>> I already posted a question regarding this to an existing thread:
>> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
>>
>> I apologize for the double posting but I have some further information
>> that might be illuminating.
>>
>> I am trying to cross-compile my R-package under ubuntu linux, kernel
>> 2.6.17-10-generic, on an IBM T60.
>>
>> I am following the suggested steps in
>> http://cran.r-project.org/doc/contrib/cross-build.pdf
>>
>> I have tried changing R = R-x.x.x (2.3.1, 2.4.0 and 2.4.1) in
>> http://cran.ii.uib.no/doc/contrib/Makefile-rcb
>>
>> 1) For R-2.3.1 everything works fine
>> 2) For R-2.4.0 I receive the following error messages from 'make R':
>>
>> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
>> more undefined references to `__pcre_ucp_findprop' follow
>> collect2: ld returned 1 exit status
>> make[4]: *** [R.dll] Error 1
>> make[3]: *** [../../bin/R.dll] Error 2
>> make[2]: *** [rbuild] Error 2
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory
>>
>> There is already a post that seems to address the same error:
>> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
>>
>> However, I have tried the suggestions there with no further success
>> and I am awaiting further instructions before pursuing that solution.
>>
>> 3) For R-2.4.1 I receive the following error message from 'make R',
>> under 'Making package tools':
>>
>> preparing package tools for lazy loading
>> Error in makeLazyLoadDB(ns, dbbase) : could not find function "seq_along"
>> Execution halted
>>
>>
>> Hope this is illuminating and that the 'bugs', whether it is in R or
>> in PCRE, can be resolved for the next release, this would be highly
>> appreciated. Meanwhile, any suggestions as to how I can cross-compile
>> successfully under R-2.4.1 are most welcome.
>>
>> Best wishes,
>> Daniel Berg
>>
>

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Vladimir Dergachev]

On Friday 19 January 2007 1:29 pm, Gabor Grothendieck wrote:
> > If you decide to use C++ with R you should check out the documentation
> > that comes with the package RcppTemplate, and the sample code that
> > comes with that package. In my experience C++ (or C or FORTRAN) is
> > needed for many compute intensive tasks, and the R framework provides
> > a nice front-end with its extensive collection of visualization and
> > statistical analysis tools.
>
> Actually I have found the opposite. I have never found C/C++ to be
> necessary. I have always been able to optimize the R code itself to get it
> to run sufficiently fast for my purposes.
>

The nice thing about being able to use C code is that this provides confidence 
that however slowly your R script runs right now you will be able to make it 
faster - no matter what.

On quite a few occasions I have started writing C code and after thinking 
about how I would structure it realized that I can do the same thing in R and 
still get 50% of the speed improvement I get from C.

Also, I am not sure whether this is mentioned anywhere, but I found it to be 
more convenient to use dyn.load directly instead of creating a full-blown R 
package. This way the edit-compile-test cycle is much more convenient.

  best

   Vladimir Dergachev

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

Re: [Rd] encoding issues even w/o accents (background on single quotes)

[Ross Boylan]

On Wed, Jan 17, 2007 at 11:56:15PM -0800, Ross Boylan wrote:
> An earlier thread (in 10/2006) discussed encoding issues in the
> context of R data and the desire to represent accented characters.
> 
> It matters in another setting: the output generated by R and the
> seemingly order character "'" (single quote).  In particular, R CMD
^^^ should be "ordinary"
> check runs test code and compares the generated output to a saved file
> of expected output.  This does not work reliably across encoding
> schemes.  This is unfortunate, since it seems the "expected output"
> files will necessarily be wrong for someone.
> 
> The problem for me was triggered by the single-quote character "'".
> On my older systems, this is encoded by 0x27, a perfectly fine ASCII
> character.  That is on a Debian GNU/Linux system with LANG=en_US.  On
> a newer system I have LANG=en_US.UTF-8.  I don't recall whether
> this was a deliberate choice on my part, or simply reflects changing
> defaults for the installer.  (Note the earlier thread referred to the
> Debian-derived Ubuntu systems as having switched to UTF-8).  Under
> UTF-8 the same character is encoded in the 3-byte sequence 0xE28098
> (which seems odd; I thought the point of UTF-8 was that ASCII was a
> legitimate subset).

Apparently quoting, particularly single quotes, is a can of worms:
http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
When Unicode is available (which would be the case with UTF-8),
particular non-ASCII characters are recommended for single quoting.
The 3 byte sequence is the UTF-8 encoding of x2018, the recommended
left single quote mark.

See http://en.wikipedia.org/wiki/UTF-8 on UTF-8 encoding.

This is more than I or, probably, you ever wanted to know about this
issue!

Ross

> 
> The coefficient  printing methods in the stats package use the
> single-quote in the key explaining significance levels:
> Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 
> 
> I suppose one possible work-around for R CMD check would be to set the
> encoding to  some standard value before it runs tests, but that has
> some drawbacks.  It doesn't work for packages needing a different
> encoding (but perhaps the package could specify an encoding to use by
> default?)(*),  It will leave the output files looking weird on systems
> with a different encoding.  It will get messed up if one generates the
> files under the wrong encoding.
> 
> And none of this addresses stuff beyond the context of output file
> comparison in R CMD check.
> 
> Any thoughts?
> 
> Ross Boylan
> 
> 
> * From the R Extensions document, discussing the DESCRIPTION file:
>If the `DESCRIPTION' file is not entirely in ASCII it should contain
> an `Encoding' field specifying an encoding.  This is currently used as
> the encoding of the `DESCRIPTION' file itself, and may in the future be
> taken as the encoding for other documentation in the package.  Only
> encoding names `latin1', `latin2' and `UTF-8' are known to be portable.
> 
> I would not expect that the test output files be considered
> "documentation," but I suppose that's subject to interpretation.

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

Re: [Rd] Cross-compile errors under R-2.4.0 and R-2.4.1

[Prof Brian Ripley]

The 2.4.0 issue has been well documented only last week, in the thread

https://stat.ethz.ch/pipermail/r-help/2007-January/123303.html

as well as in an answer I had already posted.

I am almost certain the issue for 2.4.1 is user error.  Remember you need 
to set in MkRules

## === cross-compilation settings  =

...

# path (possibly full path) to same version of R on the host system
# R_EXE=R

R 2.4.1 does have seq_along, so it must not be the same version.


On Fri, 19 Jan 2007, Daniel Berg wrote:

> Dear all,
>
> I already posted a question regarding this to an existing thread:
> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
>
> I apologize for the double posting but I have some further information
> that might be illuminating.
>
> I am trying to cross-compile my R-package under ubuntu linux, kernel
> 2.6.17-10-generic, on an IBM T60.
>
> I am following the suggested steps in
> http://cran.r-project.org/doc/contrib/cross-build.pdf
>
> I have tried changing R = R-x.x.x (2.3.1, 2.4.0 and 2.4.1) in
> http://cran.ii.uib.no/doc/contrib/Makefile-rcb
>
> 1) For R-2.3.1 everything works fine
> 2) For R-2.4.0 I receive the following error messages from 'make R':
>
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
> more undefined references to `__pcre_ucp_findprop' follow
> collect2: ld returned 1 exit status
> make[4]: *** [R.dll] Error 1
> make[3]: *** [../../bin/R.dll] Error 2
> make[2]: *** [rbuild] Error 2
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
>
> There is already a post that seems to address the same error:
> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
>
> However, I have tried the suggestions there with no further success
> and I am awaiting further instructions before pursuing that solution.
>
> 3) For R-2.4.1 I receive the following error message from 'make R',
> under 'Making package tools':
>
> preparing package tools for lazy loading
> Error in makeLazyLoadDB(ns, dbbase) : could not find function "seq_along"
> Execution halted
>
>
> Hope this is illuminating and that the 'bugs', whether it is in R or
> in PCRE, can be resolved for the next release, this would be highly
> appreciated. Meanwhile, any suggestions as to how I can cross-compile
> successfully under R-2.4.1 are most welcome.
>
> Best wishes,
> Daniel Berg
>

-- 
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] C vs. C++ as learning and development tool for R

[Gabor Grothendieck]

On 1/19/07, Dominick Samperi <[EMAIL PROTECTED]> wrote:
> Kimpel, Mark William wrote:
> > I have 3 years of experience with R and have an interest in becoming a
> > better programmer so that I might someday be able to contribute
> > packages. Other than R, my only experience was taking Lisp from Daniel
> > Friedman in the 1970's. I would like to learn either C or C++ for
> > several reasons:
> >
> > To gain a better concept of object oriented programming so that I can
> > begin to use S4 methods in R.
> >
> > To perhaps speed up some things I do repeatedly in R
> >
> > To be able to contribute a package someday.
> >
> If you decide to use C++ with R you should check out the documentation
> that comes with the package RcppTemplate, and the sample code that
> comes with that package. In my experience C++ (or C or FORTRAN) is
> needed for many compute intensive tasks, and the R framework provides
> a nice front-end with its extensive collection of visualization and
> statistical analysis tools.

Actually I have found the opposite. I have never found C/C++ to be necessary.
I have always been able to optimize the R code itself to get it to run
sufficiently fast for my purposes.

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Dominick Samperi]

Kimpel, Mark William wrote:
> I have 3 years of experience with R and have an interest in becoming a
> better programmer so that I might someday be able to contribute
> packages. Other than R, my only experience was taking Lisp from Daniel
> Friedman in the 1970's. I would like to learn either C or C++ for
> several reasons:
>
> To gain a better concept of object oriented programming so that I can
> begin to use S4 methods in R.
>
> To perhaps speed up some things I do repeatedly in R
>
> To be able to contribute a package someday.
>   
If you decide to use C++ with R you should check out the documentation
that comes with the package RcppTemplate, and the sample code that
comes with that package. In my experience C++ (or C or FORTRAN) is
needed for many compute intensive tasks, and the R framework provides
a nice front-end with its extensive collection of visualization and
statistical analysis tools.

Disclaimer: I have no experience with S4.

ds

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

[Rd] obsolescence

[Barry Rowlingson]

Since many posts to R-devel/help invoke this response:

Prof Brian Ripley wrote:
> Please, use the current version of R and not an obselete one 

is there an argument for including a version check on R startup?  These 
things seem somewhat in vogue these days (what with everything on the 
internet being in a permanent 'beta' state), and software will often 
start up with 'A new version of Foobar is available' dialog.

  Perhaps R.version could return a component that says 'current', 
'buggy', or 'obsolete' as appropriate?

  It would need a file on a well-known URL to give the version 
information, an internet connection, and a bit of R code.  And obviously 
a server capable of handling the load...

  I'd vote to have the version check off by default, perhaps settable at 
compile-time, and configurable by the usual R startup mechanism.  The 
check wouldn't run if R is running with the BATCH command.  Personally, 
I'd switch it off completely, because these things annoy me.

  Maybe this is already in R, but I'm using an obsolete version at the 
moment (2.4.0).

Barry

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

Re: [Rd] pcre library in R (PR#9319)

[Prof Brian Ripley]

Please, use the current version of R and not an obselete one (you failed 
to report the version, but you do have 'R-2.4.0' in the path name, so I 
presume that is what you are using).  This does not occur under 2.4.1.

(The problem is in the binutils you are using to cross-compile, and an 
alternative is to update that.)

If you want to fix 2.4.0 and use your cross-compiler, I think you can 
remove pcre_dfa_exec.c and remove mention of it from Makefile.win.


On Fri, 19 Jan 2007, Daniel Berg wrote:

> I have the same problem, trying to cross-compile.
>
> I'm running Ubuntu Edgy, kernel 2.6.17-10-generic, on an IBM T60.
>
> I downloaded the Makefile from CRAN and ran make CrossCompileBuild
> with the following error messages (also ran each make one at the time
> and the problem occurs in make R):
>
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1703):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1740):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1848):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x187f):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1966):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
> more undefined references to `__pcre_ucp_findprop' follow
> collect2: ld returned 1 exit status
> make[4]: *** [R.dll] Error 1
> make[3]: *** [../../bin/R.dll] Error 2
> make[2]: *** [rbuild] Error 2
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/home/daniel/Jobb/R/RCrossBuild/WinR/R-2.4.0/src/gnuwin32'
>
> Can you please report in greater detail how you added the files
> pcre_ucp_searchfuncs.c and ucptable.c Mr. Kinney?
> I have downloaded the files but I don't know where to put them, under
> /WinR/R-2.4.0/src/extra/pcre? And to which makefile, Makefilw.win?
>
> Thank you.
>
> Best wishes,
> Daniel Berg
>

-- 
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] C vs. C++ as learning and development tool for R

[Dirk Eddelbuettel]

Mark,

Great question. As Gabor said, if it is "just for R", there is no point in
learning C or C++. However, learning new programming paradigms is very useful
in and by itself, and being able to extend R with C, C++ or Fortran is
extremely useful for R.

I would suggest what I jokingly call 'C+' -- use C++, ignore many of the
advanced features for the next little while, and treat it as a 'better
C'.  There is no cost in terms of R extensibility.  Concentrate on the first
third or so of Stroustrup's book as well as others. There are also many
tutorials out there on the net.

Lastly, if it is "just" for learning other OO paradigms, Python and Ruby are
both excellent, widely used and well documented on the net. I speak neither
very well but have been meaning to learn either or both better for longer
than I'd care to admit in public.

Cheers, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison

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

Re: [Rd] combn implementation

[Giampiero Salvi]

Thank you!
It's clear now. I was not looking at the real source code, but at the
code you get from the print method (that is by simply typing combn
at the prompt), which has all the comments removed. Next time I'll
take my time looking for the real source code ;)

Thanks again,
Giampiero


On Fri, 19 Jan 2007, Martin Maechler wrote:

> > "Giampiero" == Giampiero Salvi <[EMAIL PROTECTED]>
> > on Fri, 19 Jan 2007 14:21:24 +0100 (CET) writes:
>
> Giampiero> Hi,
> Giampiero> I was checking the source code to the function combn that 
> "generates
> Giampiero> all combinations of the elements of 'x' taken 'm' at a time.",
> Giampiero> because I wished to modify it. I have a doubt about a 
> statement.
> Giampiero> This is the main loop.
>
>   > ._1 <- 1:1
>   > nmmp1 <- n - m + ._1
>   > while (a[1] != nmmp1) {
>   > if (e < n - h) {
>   > h <- ._1
>   > e <- a[m]
>   > j <- ._1
>   > }
>   > else {
>   > e <- a[m - h]
>   > h <- h + ._1
>   > j <- 1:h
>   > }
>   > a[m - h + j] <- e + j
>   > r <- if (nofun)
>   > x[a]
>   > else FUN(x[a], ...)
>   > if (simplify)
>   > out[, i] <- r
>   > else out[[i]] <- r
>   > i <- i + 1
>   > }
>
> Not really!
> You are not showing all the comments that go with it!
>  --> https://svn.R-project.org/R/trunk/src/library/utils/R/combn.R
> is the current source file of the development version whereas
>  https://svn.r-project.org/R/tags/R-2-4-1/src/library/utils/R/combn.R
> is the R-2.4.1 version
>
> Giampiero> I wonder what is the meaning of the statement "._1 <- 1:1".
>
> The "real" source in 2.4.1 says
>._1 <- 1:1 # to keep integer arithmetic
> ^
>
> So: It assigns  "1:1" {the infamous short form for as.integer(1)}
> to the variable '._1'
>
> The variable name is a bit unusual and I had a little chuckle when I
> invented it to put there.
>
> However with '1L' in R-devel, i.e. from R-2.5.0 on,
> code like the above will be definitely be simplified to use '1L'
> in such places, and then assigning it does not make sense
> anymore (of course it's questionable if it ever did make sense,
> but then, as I said, a had a chuckle and I think I found back
> then that it *did* increase speed slightly) 
>
>
> Giampiero> First question: what is the difference with "._1 <- 1"?
> explained in the comment
>
> Giampiero> Second question (perhaps answerd by the answer to the first):
>
> indeed it is.
>
> Giampiero> why not using "1" directly? E.g.:
>
> Giampiero> [...]
> Giampiero> h <- 1
> Giampiero> e <- a[m]
> Giampiero> e <- 1
> Giampiero> [...]
>
> Giampiero> Sorry if this is covered by the manuals, but it's not easy to 
> search
> Giampiero> for the string "._1" with the usual search engines.
> Giampiero> Thank you!
> Giampiero> Giampiero
>
> You're welcome.
>
> Martin Maechler, ETH Zurich
>

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

Re: [Rd] pcre library in R (PR#9319)

[Hin-Tak Leung]

The usual drill: The problem is fixed in R 2.4.1 (i.e. please do
not report bugs on old versions). In addition, you need newer mingw
than you have.

Daniel Berg wrote:
> I have the same problem, trying to cross-compile.
> 
> I'm running Ubuntu Edgy, kernel 2.6.17-10-generic, on an IBM T60.
> 
> I downloaded the Makefile from CRAN and ran make CrossCompileBuild
> with the following error messages (also ran each make one at the time
> and the problem occurs in make R):
> 
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1703):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1740):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1848):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x187f):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1966):
> undefined reference to `__pcre_ucp_findprop'
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
> more undefined references to `__pcre_ucp_findprop' follow
> collect2: ld returned 1 exit status
> make[4]: *** [R.dll] Error 1
> make[3]: *** [../../bin/R.dll] Error 2
> make[2]: *** [rbuild] Error 2
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/home/daniel/Jobb/R/RCrossBuild/WinR/R-2.4.0/src/gnuwin32'
> 
> Can you please report in greater detail how you added the files
> pcre_ucp_searchfuncs.c and ucptable.c Mr. Kinney?
> I have downloaded the files but I don't know where to put them, under
> /WinR/R-2.4.0/src/extra/pcre? And to which makefile, Makefilw.win?
> 
> Thank you.
> 
> Best wishes,
> Daniel Berg

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

Re: [Rd] Cross-compile errors under R-2.4.0 and R-2.4.1

[Hin-Tak Leung]

You missed my posts (earlier this week). The subject is:
"mingw-cross with R 2.4.x Re: [Rd] wine and build difference between 
R.2.4.0 and R 2.4.1 windows binaries?" which contains my notes on this 
subject.

Basically you need newer mingw than on Prof Ripley's web site (i.e.
you'll need to build mingw yourself), and as for the pcre error
in 2.4.0, you need to graft pcre from 2.4.1 back. Good luck.

Daniel Berg wrote:
> Dear all,
> 
> I already posted a question regarding this to an existing thread:
> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
> 
> I apologize for the double posting but I have some further information
> that might be illuminating.
> 
> I am trying to cross-compile my R-package under ubuntu linux, kernel
> 2.6.17-10-generic, on an IBM T60.
> 
> I am following the suggested steps in
> http://cran.r-project.org/doc/contrib/cross-build.pdf
> 
> I have tried changing R = R-x.x.x (2.3.1, 2.4.0 and 2.4.1) in
> http://cran.ii.uib.no/doc/contrib/Makefile-rcb
> 
> 1) For R-2.3.1 everything works fine
> 2) For R-2.4.0 I receive the following error messages from 'make R':
> 
> ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
> more undefined references to `__pcre_ucp_findprop' follow
> collect2: ld returned 1 exit status
> make[4]: *** [R.dll] Error 1
> make[3]: *** [../../bin/R.dll] Error 2
> make[2]: *** [rbuild] Error 2
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> 
> There is already a post that seems to address the same error:
> http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start
> 
> However, I have tried the suggestions there with no further success
> and I am awaiting further instructions before pursuing that solution.
> 
> 3) For R-2.4.1 I receive the following error message from 'make R',
> under 'Making package tools':
> 
> preparing package tools for lazy loading
> Error in makeLazyLoadDB(ns, dbbase) : could not find function "seq_along"
> Execution halted
> 
> 
> Hope this is illuminating and that the 'bugs', whether it is in R or
> in PCRE, can be resolved for the next release, this would be highly
> appreciated. Meanwhile, any suggestions as to how I can cross-compile
> successfully under R-2.4.1 are most welcome.
> 
> Best wishes,
> Daniel Berg

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Ramon Diaz-Uriarte]

Dear Mark,

On Friday 19 January 2007 09:55, Kimpel, Mark William wrote:
> I have 3 years of experience with R and have an interest in becoming a
> better programmer so that I might someday be able to contribute
> packages. Other than R, my only experience was taking Lisp from Daniel
> Friedman in the 1970's. I would like to learn either C or C++ for
> several reasons:
>
> To gain a better concept of object oriented programming so that I can
> begin to use S4 methods in R.
>

I do not think C++ is the best idea if you are learning it to understand the 
OOP of R. The OOP of R is probably closer to that of CLOS (the common lisp 
object system) than C++ and Java.

It might be better to directly go ahead and look for documentation specificaly 
about R's OOP.

> To perhaps speed up some things I do repeatedly in R
>
> To be able to contribute a package someday.
>
>
>
> I have been doing some reading and from what I can tell R is more
> compatible with C, but C++ has much greater capabilities for OO
> programming.
>
>
>
> I have just started reading The C++ Programming Language: Special
> Edition by Bjarne Stroustrup
>  ustrup&z=y> , he recommends first learning C++ and then then C if
> necessary, but as a developer of C++, he is probably biased.
>
>
>
> I would greatly appreciate the advice of the R developers and package
> contributors on this subject. "C" or "C++"?
>
>

I'd recommend C instead of C++: C++ is a huge language and it is somewhat 
easier to interface C than C++ from R. (In "non-R" stuff I prefer to use C++ 
better than C, even if just as in "C++as a better C", but this probably is 
not a reasonable reason to learn C++).  

HTH,

R.



>
> Thanks,
>
>
>
> Mark
>
>
>
> Mark W. Kimpel MD
>
>
>
>
>
> Official Business Address:
>
>
>
> Department of Psychiatry
>
> Indiana University School of Medicine
>
> PR M116
>
> Institute of Psychiatric Research
>
> 791 Union Drive
>
> Indianapolis, IN 46202
>
>
>
> Preferred Mailing Address:
>
>
>
> 15032 Hunter Court
>
> Westfield, IN  46074
>
>
>
> (317) 490-5129 Work, & Mobile
>
>
>
> (317) 663-0513 Home (no voice mail please)
>
> 1-(317)-536-2730 FAX
>
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Ramón Díaz-Uriarte
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900

http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)



**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Gabor Grothendieck]

You don't necessarily need to know C or C++ to write an R package.
Many (maybe most) R packages only use R.

On 1/19/07, Kimpel, Mark William <[EMAIL PROTECTED]> wrote:
> I have 3 years of experience with R and have an interest in becoming a
> better programmer so that I might someday be able to contribute
> packages. Other than R, my only experience was taking Lisp from Daniel
> Friedman in the 1970's. I would like to learn either C or C++ for
> several reasons:
>
> To gain a better concept of object oriented programming so that I can
> begin to use S4 methods in R.
>
> To perhaps speed up some things I do repeatedly in R
>
> To be able to contribute a package someday.
>
>
>
> I have been doing some reading and from what I can tell R is more
> compatible with C, but C++ has much greater capabilities for OO
> programming.
>
>
>
> I have just started reading The C++ Programming Language: Special
> Edition by Bjarne Stroustrup
>  ustrup&z=y> , he recommends first learning C++ and then then C if
> necessary, but as a developer of C++, he is probably biased.
>
>
>
> I would greatly appreciate the advice of the R developers and package
> contributors on this subject. "C" or "C++"?
>
>
>
> Thanks,
>
>
>
> Mark
>
>
>
> Mark W. Kimpel MD
>
>
>
>
>
> Official Business Address:
>
>
>
> Department of Psychiatry
>
> Indiana University School of Medicine
>
> PR M116
>
> Institute of Psychiatric Research
>
> 791 Union Drive
>
> Indianapolis, IN 46202
>
>
>
> Preferred Mailing Address:
>
>
>
> 15032 Hunter Court
>
> Westfield, IN  46074
>
>
>
> (317) 490-5129 Work, & Mobile
>
>
>
> (317) 663-0513 Home (no voice mail please)
>
> 1-(317)-536-2730 FAX
>
>
>[[alternative HTML version deleted]]
>
> __
> 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] combn implementation

[Wolfgang Huber]

Dear Giampiero,

> storage.mode(1)
[1] "double"
> storage.mode(1:1)
[1] "integer"

as.integer(1) would perhaps be the more pedagogical way to program this.

 Best wishes
 Wolfgang

--
Wolfgang Huber  EBI/EMBL  Cambridge UK  http://www.ebi.ac.uk/huber


> Hi,
> I was checking the source code to the function combn that "generates
> all combinations of the elements of 'x' taken 'm' at a time.",
> because I wished to modify it. I have a doubt about a statement.
> This is the main loop.
> 
> ._1 <- 1:1
> nmmp1 <- n - m + ._1
> while (a[1] != nmmp1) {
> if (e < n - h) {
> h <- ._1
> e <- a[m]
> j <- ._1
> }
> else {
> e <- a[m - h]
> h <- h + ._1
> j <- 1:h
> }
> a[m - h + j] <- e + j
> r <- if (nofun)
> x[a]
> else FUN(x[a], ...)
> if (simplify)
> out[, i] <- r
> else out[[i]] <- r
> i <- i + 1
> }
> 
> I wonder what is the meaning of the statement "._1 <- 1:1".
> First question: what is the difference with "._1 <- 1"?
> Second question (perhaps answerd by the answer to the first): why not
> using "1" directly? E.g.:
> [...]
> h <- 1
> e <- a[m]
> e <- 1
> [...]
> 
> Sorry if this is covered by the manuals, but it's not easy to search
> for the string "._1" with the usual search engines.
> Thank you!
> Giampiero

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

Re: [Rd] C vs. C++ as learning and development tool for R

[Duncan Murdoch]

On 1/19/2007 3:55 AM, Kimpel, Mark William wrote:
> I have 3 years of experience with R and have an interest in becoming a
> better programmer so that I might someday be able to contribute
> packages. Other than R, my only experience was taking Lisp from Daniel
> Friedman in the 1970's. I would like to learn either C or C++ for
> several reasons:
> 
> To gain a better concept of object oriented programming so that I can
> begin to use S4 methods in R.
> 
> To perhaps speed up some things I do repeatedly in R
> 
> To be able to contribute a package someday.
> 
>  
> 
> I have been doing some reading and from what I can tell R is more
> compatible with C, but C++ has much greater capabilities for OO
> programming.
> 
>  
> 
> I have just started reading The C++ Programming Language: Special
> Edition by Bjarne Stroustrup
>  ustrup&z=y> , he recommends first learning C++ and then then C if
> necessary, but as a developer of C++, he is probably biased.
> 
>  
> 
> I would greatly appreciate the advice of the R developers and package
> contributors on this subject. "C" or "C++"?

For your purposes, I would recommend C.  Most example code you'll find 
is written in C, so it's easier to learn by looking at simple examples 
written by others.  The R external interface was designed with C in 
mind, so you need to tell C++ to act like C to use it.

Regarding OOP, I think the C++ style of OOP is so different from S4 that 
it would not actually be helpful in learning S4.  As far as I know, none 
of the languages that are easy to link to R use the same style of OOP.

On the other hand, taking a disciplined approach to C programming is a 
good idea (which is I think what Stroustrup had in mind).  I'd suggest 
an object oriented Pascal (e.g. Delphi) or Java if that's what you want, 
  because they are simpler than C++.  C and R are very permissive 
languages, and if you take advantage of that you can write amazingly 
sloppy and unmaintainable code.

Duncan Murdoch

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

Re: [Rd] combn implementation

[Martin Maechler]

> "Giampiero" == Giampiero Salvi <[EMAIL PROTECTED]>
> on Fri, 19 Jan 2007 14:21:24 +0100 (CET) writes:

Giampiero> Hi,
Giampiero> I was checking the source code to the function combn that 
"generates
Giampiero> all combinations of the elements of 'x' taken 'm' at a time.",
Giampiero> because I wished to modify it. I have a doubt about a statement.
Giampiero> This is the main loop.

  > ._1 <- 1:1
  > nmmp1 <- n - m + ._1
  > while (a[1] != nmmp1) {
  > if (e < n - h) {
  > h <- ._1
  > e <- a[m]
  > j <- ._1
  > }
  > else {
  > e <- a[m - h]
  > h <- h + ._1
  > j <- 1:h
  > }
  > a[m - h + j] <- e + j
  > r <- if (nofun)
  > x[a]
  > else FUN(x[a], ...)
  > if (simplify)
  > out[, i] <- r
  > else out[[i]] <- r
  > i <- i + 1
  > }

Not really!  
You are not showing all the comments that go with it!
 --> https://svn.R-project.org/R/trunk/src/library/utils/R/combn.R
is the current source file of the development version whereas
 https://svn.r-project.org/R/tags/R-2-4-1/src/library/utils/R/combn.R
is the R-2.4.1 version

Giampiero> I wonder what is the meaning of the statement "._1 <- 1:1".

The "real" source in 2.4.1 says
   ._1 <- 1:1 # to keep integer arithmetic
  ^

So: It assigns  "1:1" {the infamous short form for as.integer(1)}
to the variable '._1'

The variable name is a bit unusual and I had a little chuckle when I
invented it to put there.

However with '1L' in R-devel, i.e. from R-2.5.0 on,
code like the above will be definitely be simplified to use '1L'
in such places, and then assigning it does not make sense
anymore (of course it's questionable if it ever did make sense,
but then, as I said, a had a chuckle and I think I found back
then that it *did* increase speed slightly) 


Giampiero> First question: what is the difference with "._1 <- 1"?
explained in the comment

Giampiero> Second question (perhaps answerd by the answer to the first): 

indeed it is.

Giampiero> why not using "1" directly? E.g.:

Giampiero> [...]
Giampiero> h <- 1
Giampiero> e <- a[m]
Giampiero> e <- 1
Giampiero> [...]

Giampiero> Sorry if this is covered by the manuals, but it's not easy to 
search
Giampiero> for the string "._1" with the usual search engines.
Giampiero> Thank you!
Giampiero> Giampiero

You're welcome.

Martin Maechler, ETH Zurich

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

[Rd] Cross-compile errors under R-2.4.0 and R-2.4.1

[Daniel Berg]

Dear all,

I already posted a question regarding this to an existing thread:
http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start

I apologize for the double posting but I have some further information
that might be illuminating.

I am trying to cross-compile my R-package under ubuntu linux, kernel
2.6.17-10-generic, on an IBM T60.

I am following the suggested steps in
http://cran.r-project.org/doc/contrib/cross-build.pdf

I have tried changing R = R-x.x.x (2.3.1, 2.4.0 and 2.4.1) in
http://cran.ii.uib.no/doc/contrib/Makefile-rcb

1) For R-2.3.1 everything works fine
2) For R-2.4.0 I receive the following error messages from 'make R':

../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
more undefined references to `__pcre_ucp_findprop' follow
collect2: ld returned 1 exit status
make[4]: *** [R.dll] Error 1
make[3]: *** [../../bin/R.dll] Error 2
make[2]: *** [rbuild] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory

There is already a post that seems to address the same error:
http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0852.html#start

However, I have tried the suggestions there with no further success
and I am awaiting further instructions before pursuing that solution.

3) For R-2.4.1 I receive the following error message from 'make R',
under 'Making package tools':

preparing package tools for lazy loading
Error in makeLazyLoadDB(ns, dbbase) : could not find function "seq_along"
Execution halted


Hope this is illuminating and that the 'bugs', whether it is in R or
in PCRE, can be resolved for the next release, this would be highly
appreciated. Meanwhile, any suggestions as to how I can cross-compile
successfully under R-2.4.1 are most welcome.

Best wishes,
Daniel Berg
-- 
danielberg.no

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

[Rd] C vs. C++ as learning and development tool for R

[Kimpel, Mark William]

I have 3 years of experience with R and have an interest in becoming a
better programmer so that I might someday be able to contribute
packages. Other than R, my only experience was taking Lisp from Daniel
Friedman in the 1970's. I would like to learn either C or C++ for
several reasons:

To gain a better concept of object oriented programming so that I can
begin to use S4 methods in R.

To perhaps speed up some things I do repeatedly in R

To be able to contribute a package someday.

 

I have been doing some reading and from what I can tell R is more
compatible with C, but C++ has much greater capabilities for OO
programming.

 

I have just started reading The C++ Programming Language: Special
Edition by Bjarne Stroustrup
 , he recommends first learning C++ and then then C if
necessary, but as a developer of C++, he is probably biased.

 

I would greatly appreciate the advice of the R developers and package
contributors on this subject. "C" or "C++"?

 

Thanks,

 

Mark

 

Mark W. Kimpel MD 

 

 

Official Business Address:

 

Department of Psychiatry

Indiana University School of Medicine

PR M116

Institute of Psychiatric Research

791 Union Drive

Indianapolis, IN 46202

 

Preferred Mailing Address:

 

15032 Hunter Court

Westfield, IN  46074

 

(317) 490-5129 Work, & Mobile

 

(317) 663-0513 Home (no voice mail please)

1-(317)-536-2730 FAX


[[alternative HTML version deleted]]

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

Re: [Rd] pcre library in R (PR#9319)

[Daniel Berg]

I have the same problem, trying to cross-compile.

I'm running Ubuntu Edgy, kernel 2.6.17-10-generic, on an IBM T60.

I downloaded the Makefile from CRAN and ran make CrossCompileBuild
with the following error messages (also ran each make one at the time
and the problem occurs in make R):

../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1703):
undefined reference to `__pcre_ucp_findprop'
../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1740):
undefined reference to `__pcre_ucp_findprop'
../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1848):
undefined reference to `__pcre_ucp_findprop'
../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x187f):
undefined reference to `__pcre_ucp_findprop'
../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1966):
undefined reference to `__pcre_ucp_findprop'
../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1f2a):
more undefined references to `__pcre_ucp_findprop' follow
collect2: ld returned 1 exit status
make[4]: *** [R.dll] Error 1
make[3]: *** [../../bin/R.dll] Error 2
make[2]: *** [rbuild] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/daniel/Jobb/R/RCrossBuild/WinR/R-2.4.0/src/gnuwin32'

Can you please report in greater detail how you added the files
pcre_ucp_searchfuncs.c and ucptable.c Mr. Kinney?
I have downloaded the files but I don't know where to put them, under
/WinR/R-2.4.0/src/extra/pcre? And to which makefile, Makefilw.win?

Thank you.

Best wishes,
Daniel Berg
-- 
danielberg.no

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

[Rd] combn implementation

[Giampiero Salvi]

Hi,
I was checking the source code to the function combn that "generates
all combinations of the elements of 'x' taken 'm' at a time.",
because I wished to modify it. I have a doubt about a statement.
This is the main loop.

._1 <- 1:1
nmmp1 <- n - m + ._1
while (a[1] != nmmp1) {
if (e < n - h) {
h <- ._1
e <- a[m]
j <- ._1
}
else {
e <- a[m - h]
h <- h + ._1
j <- 1:h
}
a[m - h + j] <- e + j
r <- if (nofun)
x[a]
else FUN(x[a], ...)
if (simplify)
out[, i] <- r
else out[[i]] <- r
i <- i + 1
}

I wonder what is the meaning of the statement "._1 <- 1:1".
First question: what is the difference with "._1 <- 1"?
Second question (perhaps answerd by the answer to the first): why not
using "1" directly? E.g.:
[...]
h <- 1
e <- a[m]
e <- 1
[...]

Sorry if this is covered by the manuals, but it's not easy to search
for the string "._1" with the usual search engines.
Thank you!
Giampiero

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