Re: [Rd] Compatibility of external C code across platforms

2009-09-26 Thread William Dunlap 
Even though the C99 standard allows variable length
arrays on the stack, I would avoid using them much
as the stack is a much more limited resource than the
heap (where malloc allocates memory).  A typical stack
has a few megabytes while a typical heap has a few
gigabytes.  Detecting stack overflows can be hard.

Bill Dunlap
TIBCO Spotfire
wdunlap tibco.com



-Original Message-
From: r-devel-boun...@r-project.org on behalf of Murray Efford
Sent: Sat 9/26/2009 3:25 AM
To: Prof Brian Ripley
Cc: r-de...@lists.r-project.org
Subject: Re: [Rd] Compatibility of external C code across platforms
 
Thank you. I'm much clearer on this. I now notice that the messages from gcc 
distinguish breaches of ISO C and ISO C90, and can see the significance.  My 
gcc versions were the same - the different behaviour is likely to be explained 
by the --std flag. And it looks like I have to re-write a lot of C to eliminate 
nesting of functions.  Point taken about HTML.
Murray Efford

From: Prof Brian Ripley [rip...@stats.ox.ac.uk]
Sent: Saturday, 26 September 2009 9:40 p.m.
To: Murray Efford
Cc: r-de...@lists.r-project.org
Subject: Re: [Rd] Compatibility of external C code across platforms

On Sat, 26 Sep 2009, Murray Efford wrote:

> A package I have written makes considerable use of external C code.
> There appear to be no problems building a Windows binary with the
> GNU C compiler, but now I would like to make the package available
> for other platforms.  A stringent check of the code with the gcc
> options '-Wall -pedantic' flags many nested functions and
> variable-length arrays that are not allowed in ISO C.  Is it
> essential that distributed C source code for R packages conforms to
> ISO C in this respect?  I'm working in Windows XP with R2.9.2 and
> Rtools 2.9.

Yes, it is essential.  R does not assume gcc, and it does not even
assume gcc 4.x (and people are still using gcc 3.x on some platforms,
e.g. the sunfreeware R builds).  This is why we publish test result on
CRAN for a completely different compiler (from SunPro).

However, if is not clear which standard you mean by 'ISO C': assuming
C99 is fairly safe, but GNU extensions from C99 are not -- nested
functions are one such.

> [Incidentally, when I use a makevars.win file to include these gcc
> options in Rcmd build etc. the problem with variable-length arrays
> is not flagged; maybe my command-line gcc is a different version
> from that in Rtools]

Well, you (and only you) can easily check that for yourself, but the
other flags also matter, especially --std.  Because it has been needed
for the use of the MinGW headers, R on Windows is built with
--std=gnu99.  (Linux headers have a similar problem: using --std=c99
disables some features we test for in configure and wish to use -- and
there are OS features, not language extensions.)

>
> Murray Efford
> University of Otago
> Dunedin, New Zealand
> murray.eff...@otago.ac.nz
>
>   [[alternative HTML version deleted]]

Please note what the posting guide has to say about that.

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

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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


[[alternative HTML version deleted]]

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

[Rd] Rtools210 missing jpeg-7?

2009-09-26 Thread Hiroyuki Kawakatsu 
Hi,

I just built r49839 on my windoze machine with Rtools210. When I do
-make bitmapdll-, it errors saying file jpeg-7/jconfig.h not found
(apologies, I lost the exact error message). After downloading and
unpacking jpegsr7.zip, the bitmap dll builds fine. Rtools210 appears
to still install jpeg-6b, whereas the bitmap makefile (first line) is
expecting jpeg-7. Perhaps this is still experimental but either Rtools
should include jpeg-7 or the makefile should default to jpeg-6b?

documentation note: the bitmap dll paths R_HOME/bin/Rbitmap.dll in
R-admin should be updated to R_HOME/library/grDevices/libs/.

h.
-- 
+---
| Hiroyuki Kawakatsu
| Business School, Dublin City University
| Dublin 9, Ireland. Tel +353 (0)1 700 7496

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

Re: [Rd] Compatibility of external C code across platforms

2009-09-26 Thread Prof Brian Ripley 

On Sat, 26 Sep 2009, Murray Efford wrote:

A package I have written makes considerable use of external C code. 
There appear to be no problems building a Windows binary with the 
GNU C compiler, but now I would like to make the package available 
for other platforms.  A stringent check of the code with the gcc 
options '-Wall -pedantic' flags many nested functions and 
variable-length arrays that are not allowed in ISO C.  Is it 
essential that distributed C source code for R packages conforms to 
ISO C in this respect?  I'm working in Windows XP with R2.9.2 and 
Rtools 2.9.


Yes, it is essential.  R does not assume gcc, and it does not even 
assume gcc 4.x (and people are still using gcc 3.x on some platforms, 
e.g. the sunfreeware R builds).  This is why we publish test result on 
CRAN for a completely different compiler (from SunPro).


However, if is not clear which standard you mean by 'ISO C': assuming 
C99 is fairly safe, but GNU extensions from C99 are not -- nested 
functions are one such.


[Incidentally, when I use a makevars.win file to include these gcc 
options in Rcmd build etc. the problem with variable-length arrays 
is not flagged; maybe my command-line gcc is a different version 
from that in Rtools]


Well, you (and only you) can easily check that for yourself, but the 
other flags also matter, especially --std.  Because it has been needed 
for the use of the MinGW headers, R on Windows is built with 
--std=gnu99.  (Linux headers have a similar problem: using --std=c99 
disables some features we test for in configure and wish to use -- and 
there are OS features, not language extensions.)




Murray Efford
University of Otago
Dunedin, New Zealand
murray.eff...@otago.ac.nz

[[alternative HTML version deleted]]


Please note what the posting guide has to say about that.



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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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] mboost_1.1-3 blackboost_fit (PR#13972)

2009-09-26 Thread bullshit 
Full_Name: Ivan the Terrible
Version: 2.9.2
OS: Windows XP SP3
Submission from: (NULL) (89.110.13.151)


When using the method blackboost_fit of the package mboost appear following
error :
Error in party:::get_variables(o...@responses) : 
  trying to get slot "responses" from an object (class "boost_data") that is not
an S4 object

Simple test case that produce bug:

dt=expand.grid(y=c(2,3,4), x1=c(1,2), x2=c(1,2))
library(mboost)
bd=boost_dpp(y ~ .,data=dt, weights = NULL)
blackboost_fit(bd, 
   tree_controls = ctree_control(
 teststat = "max",
 testtype = "Teststatistic",
 mincriterion = 0,
 maxdepth = 2
),
   fitmem = ctree_memory(
 bd, 
 TRUE
), 
   family = GaussReg(),
   control = boost_control(
   mstop = 2
  ), 
   weights = NULL
  )


Test case session on my computer:

> dt=expand.grid(y=c(2,3,4), x1=c(1,2), x2=c(1,2))
> library(mboost)
Loading required package: modeltools
Loading required package: stats4
Loading required package: party
Loading required package: survival
Loading required package: splines
Loading required package: grid
Loading required package: coin
Loading required package: mvtnorm
Loading required package: zoo

Attaching package: 'zoo'


The following object(s) are masked from package:base :

 as.Date.numeric 

Loading required package: sandwich
Loading required package: strucchange
Loading required package: vcd
Loading required package: MASS
Loading required package: colorspace
> bd=boost_dpp(y ~ .,data=dt, weights = NULL)
> blackboost_fit(bd, 
+tree_controls = ctree_control(
+  teststat = "max",
+  testtype = "Teststatistic",
+  mincriterion = 0,
+  maxdepth = 2
+ ),
+fitmem = ctree_memory(
+  bd, 
+  TRUE
+ ), 
+family = GaussReg(),
+control = boost_control(
+mstop = 2
+   ), 
+weights = NULL
+   )
Error in party:::get_variables(o...@responses) : 
  trying to get slot "responses" from an object (class "boost_data") that is not
an S4 object 
> sessionInfo()
R version 2.9.2 (2009-08-24) 
i386-pc-mingw32 

locale:
LC_COLLATE=Russian_Russia.1251;LC_CTYPE=Russian_Russia.1251;LC_MONETARY=Russian_Russia.1251;LC_NUMERIC=C;LC_TIME=Russian_Russia.1251

attached base packages:
[1] grid  splines   stats graphics  grDevices utils datasets 
methods   base 

other attached packages:
 [1] mboost_1.1-3  party_0.9-999 vcd_1.2-4 colorspace_1.0-1 
MASS_7.2-48   strucchange_1.3-7
 [7] sandwich_2.2-1zoo_1.5-8 coin_1.0-6mvtnorm_0.9-7
survival_2.35-4   modeltools_0.2-16

loaded via a namespace (and not attached):
[1] lattice_0.17-25 stats4_2.9.2   
>

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

[Rd] xaxs disactivated when asp=1 in plots (PR#13971)

2009-09-26 Thread francois_birgand 
Full_Name: François Birgand
Version: 2.9.0
OS: windows xp
Submission from: (NULL) (152.1.16.161)


When I type this sequence:

x11()
Ylim<-c(0,14)
Xlim<-c(0,14)
plot(0,0,xlim=Xlim,ylim=Ylim,col="white",main="",xlab="",ylab="",bty="n",xaxt="n",yaxt="n",xaxs="i",yaxs="i",asp=1)
abline(h=c(0,14),lwd=2,col="grey")
abline(v=c(0,14),lwd=2,col="grey")
par(new=TRUE)
abline(h=seq(0,14,by=0.2),lty=3,col="grey")
abline(h=seq(0,14,by=1),lty=1,col="grey")
abline(v=seq(0,14,by=0.2),lty=3,col="grey")
abline(v=seq(0,14,by=1),lty=1,col="grey")
par(new=TRUE)

only yaxs="i" is taken into account while xaxs="i" is ignored.  When I remove
asp=1, xaxs="i" is activated again.
Small bug but kind of bothersome...!!

Congratulations for the great work you guys are doing!
François

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

Re: [Rd] Rtools210 missing jpeg-7?

2009-09-26 Thread Duncan Murdoch 

Hiroyuki Kawakatsu wrote:

Hi,

I just built r49839 on my windoze machine with Rtools210. When I do
-make bitmapdll-, it errors saying file jpeg-7/jconfig.h not found
(apologies, I lost the exact error message). After downloading and
unpacking jpegsr7.zip, the bitmap dll builds fine. Rtools210 appears
to still install jpeg-6b, whereas the bitmap makefile (first line) is
expecting jpeg-7. Perhaps this is still experimental but either Rtools
should include jpeg-7 or the makefile should default to jpeg-6b?

documentation note: the bitmap dll paths R_HOME/bin/Rbitmap.dll in
R-admin should be updated to R_HOME/library/grDevices/libs/.

h.
  
Thanks.  I'm on the road for a few days, so this might not get fixed 
right away, but you've found the workaround.


Duncan Murdoch

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

Re: [Rd] Compatibility of external C code across platforms

2009-09-26 Thread Murray Efford 
Thank you. I'm much clearer on this. I now notice that the messages from gcc 
distinguish breaches of ISO C and ISO C90, and can see the significance.  My 
gcc versions were the same - the different behaviour is likely to be explained 
by the --std flag. And it looks like I have to re-write a lot of C to eliminate 
nesting of functions.  Point taken about HTML.
Murray Efford

From: Prof Brian Ripley [rip...@stats.ox.ac.uk]
Sent: Saturday, 26 September 2009 9:40 p.m.
To: Murray Efford
Cc: r-de...@lists.r-project.org
Subject: Re: [Rd] Compatibility of external C code across platforms

On Sat, 26 Sep 2009, Murray Efford wrote:

> A package I have written makes considerable use of external C code.
> There appear to be no problems building a Windows binary with the
> GNU C compiler, but now I would like to make the package available
> for other platforms.  A stringent check of the code with the gcc
> options '-Wall -pedantic' flags many nested functions and
> variable-length arrays that are not allowed in ISO C.  Is it
> essential that distributed C source code for R packages conforms to
> ISO C in this respect?  I'm working in Windows XP with R2.9.2 and
> Rtools 2.9.

Yes, it is essential.  R does not assume gcc, and it does not even
assume gcc 4.x (and people are still using gcc 3.x on some platforms,
e.g. the sunfreeware R builds).  This is why we publish test result on
CRAN for a completely different compiler (from SunPro).

However, if is not clear which standard you mean by 'ISO C': assuming
C99 is fairly safe, but GNU extensions from C99 are not -- nested
functions are one such.

> [Incidentally, when I use a makevars.win file to include these gcc
> options in Rcmd build etc. the problem with variable-length arrays
> is not flagged; maybe my command-line gcc is a different version
> from that in Rtools]

Well, you (and only you) can easily check that for yourself, but the
other flags also matter, especially --std.  Because it has been needed
for the use of the MinGW headers, R on Windows is built with
--std=gnu99.  (Linux headers have a similar problem: using --std=c99
disables some features we test for in configure and wish to use -- and
there are OS features, not language extensions.)

>
> Murray Efford
> University of Otago
> Dunedin, New Zealand
> murray.eff...@otago.ac.nz
>
>   [[alternative HTML version deleted]]

Please note what the posting guide has to say about that.

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

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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