[Rd] invalid alignment error in R-2.4.0

[Robin Hankin]

Hi

I  thought I'd  pass one of my package through R CMD check with R-2.4.0
with the following result (it's clean under R-2.3.1):


[snip]
 >
 >   # histogram of the fourth power:
 > hist(out^4, col="gray")

*** caught bus error ***
address 0x12, cause 'invalid alignment'

Traceback:
1: sort(x, partial = c(half, half + 1))
2: sum(sort(x, partial = c(half, half + 1))[c(half, half + 1)])
3: stats::median(diff(breaks))
4: hist.default(out^4, col = "gray")
5: hist(out^4, col = "gray")
aborting ...



Under R-2.4.0, hist(out^4) repeatably gives an error like that above.
Here's a dput() of out:


c(10.4975870476354, 10.3973239490546, 10.9079973318563,  
10.9201457586087,
10.863164987001, 10.8092412328219, 10.3740979640666, 10.3933170416021,
10.1571361926693, 10.7231637475341, 10.8495903667896, 10.2760101321262,
10.3999724625721, 11.1422484374362, 10.1623400428855, 10.9139189812841,
11.1313700266654, 10.4214929867460, 10.9543767973144, 10.2925796047365,
10.3399040002101, 10.5080265067013, 10.4963598344302, 10.5694912655817,
10.9088365086950, 9.67007136377566, 10.4303159857457, 10.6734035266469,
10.3555432530979, 10.9738495753501, 10.350313651, 11.2210598170116,
10.8020906590915, 10.7391185468963, 10.3303267171864, 10.7176410493307,
10.3527634000890, 10.6331145125840, 10.7946862157461, 10.6147608946858,
9.85567630738787, 11.0289144282434, 10.742857648964, 10.866630627911,
10.5278318354308, 10.3553983376990, 10.7900270843436, 10.3467961125517,
10.5126782499258, 10.8575135939962, 10.9151746119094, 11.2000951011802,
10.4133108985045, 10.5265186993107, 10.7148111540688, 10.3722159808052,
10.1911424590529, 10.8375326158672, 10.2892046453081, 11.0159788575821,
10.2104834661186, 10.0718751926059, 11.5503607473136, 10.9134877529340,
11.3063246702428, 10.0682022386836, 10.6766007351429, 10.6029531885996,
10.3568338147980, 10.5246512104442, 10.9964827564484, 10.4826791470128,
10.334098026, 10.4201862775486, 10.6526293411458, 10.1270181743699,
10.7479561453406, 10.3223366380115, 10.6640317023258, 10.8816465650639,
10.2469734194448, 11.0595077832844, 10.6211764829084, 10.8387020014927,
10.3842712860829, 10.3288969420998, 11.1095936345021, 10.7755741380517,
10.8891163113089, 10.9239878986268, 10.4674437486482, 10.4494516106226,
10.6816375084280, 10.1609470064992, 10.6055689487767, 10.3759153410817,
10.4743618410399, 10.9932886540585, 10.2563007403496, 10.0821264920858,
10.7293259154111, 10.8834112318584, 10.5285102045021, 10.7068278466484,
10.9517121917501, 10.6249671128484, 10.8188751147001, 10.5327448695580,
10.7315642237059, 10.4996799637132)


 > R.version
_
platform   powerpc-apple-darwin8.7.0
arch   powerpc
os darwin8.7.0
system powerpc, darwin8.7.0
status Under development (unstable)
major  2
minor  4.0
year   2006
month  07
day09
svn rev38523
language   R
version.string R version 2.4.0 Under development (unstable)  
(2006-07-09 r38523)
 >

--
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

[Rd] Documentation: add a bit note (PR#9066)

[feimingchen]

Full_Name: Feiming Chen
Version: 2.0.0
OS: Unix
Submission from: (NULL) (216.52.132.10)


Just a note to clarify the document "Writing R Extensions". 

As a beginner, I was a little confused about this paragraph:

Section 1.1.4 Package subdirectories, page 6, the paragraph in the
middle:  "The 'man' subdirectory ... Note that all user-level objects in a
package should be documented; if a package pkg contains user-level objects which
are for 'internal' only, it should provide a file pkg-internal.Rd which
documents all such objects, and clearly states that these are not meant to be
called by the user. See e.g. the sources for package grid in the R distribution
for an example."

I just try to skip writing Rd 
files for numerous small R functions (for "internal" use, that is, called 
by other functions).  I thought the only way is to put them in
pkg-internal.Rd until I read about NAMESPACE in section 1.6. 
I find out I just need to export those R functions that are needed by
the user and then "R CMD check" won't complain not seeing the docs for 
all other functions, along with some error messages. 

So maybe we can add a footnote there that says:

Refer to section 1.6 NAMESPACE.  You can export only a subset of all R
objects to make them on user level. So that you don't need to write
Rd files for un-exported ones. 

Thanks!

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

Re: [Rd] invalid alignment error in R-2.4.0

[Martin Maechler]

I assume this is specific to your installation of R-devel
(R-2.4.0 "unstable").  If I use your 'out',
   hist(out^4, col = "gray")
works just fine consistently.

Could it be a compiler / linker mismatch
on your Mac?  Also, can you run "under the debugger"
   'R -d gdb' (from a commandline) ?

This should allow a traceback ('backtrace', abbreviated 'bt' in "gdb")
of the C call stack.

Martin

> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> on Tue, 11 Jul 2006 08:46:17 +0100 writes:

Robin> Hi
Robin> I  thought I'd  pass one of my package through R CMD check with 
R-2.4.0
Robin> with the following result (it's clean under R-2.3.1):


Robin> [snip]
>> 
>> # histogram of the fourth power:
>> hist(out^4, col="gray")

Robin> *** caught bus error ***
Robin> address 0x12, cause 'invalid alignment'

Robin> Traceback:
Robin> 1: sort(x, partial = c(half, half + 1))
Robin> 2: sum(sort(x, partial = c(half, half + 1))[c(half, half + 1)])
Robin> 3: stats::median(diff(breaks))
Robin> 4: hist.default(out^4, col = "gray")
Robin> 5: hist(out^4, col = "gray")
Robin> aborting ...



Robin> Under R-2.4.0, hist(out^4) repeatably gives an error like that above.
Robin> Here's a dput() of out:


Robin> c(10.4975870476354, 10.3973239490546, 10.9079973318563,  
Robin> 10.9201457586087,
Robin> 10.863164987001, 10.8092412328219, 10.3740979640666, 
10.3933170416021,
Robin> 10.1571361926693, 10.7231637475341, 10.8495903667896, 
10.2760101321262,
Robin> 10.3999724625721, 11.1422484374362, 10.1623400428855, 
10.9139189812841,
Robin> 11.1313700266654, 10.4214929867460, 10.9543767973144, 
10.2925796047365,
Robin> 10.3399040002101, 10.5080265067013, 10.4963598344302, 
10.5694912655817,
Robin> 10.9088365086950, 9.67007136377566, 10.4303159857457, 
10.6734035266469,
Robin> 10.3555432530979, 10.9738495753501, 10.350313651, 
11.2210598170116,
Robin> 10.8020906590915, 10.7391185468963, 10.3303267171864, 
10.7176410493307,
Robin> 10.3527634000890, 10.6331145125840, 10.7946862157461, 
10.6147608946858,
Robin> 9.85567630738787, 11.0289144282434, 10.742857648964, 10.866630627911,
Robin> 10.5278318354308, 10.3553983376990, 10.7900270843436, 
10.3467961125517,
Robin> 10.5126782499258, 10.8575135939962, 10.9151746119094, 
11.2000951011802,
Robin> 10.4133108985045, 10.5265186993107, 10.7148111540688, 
10.3722159808052,
Robin> 10.1911424590529, 10.8375326158672, 10.2892046453081, 
11.0159788575821,
Robin> 10.2104834661186, 10.0718751926059, 11.5503607473136, 
10.9134877529340,
Robin> 11.3063246702428, 10.0682022386836, 10.6766007351429, 
10.6029531885996,
Robin> 10.3568338147980, 10.5246512104442, 10.9964827564484, 
10.4826791470128,
Robin> 10.334098026, 10.4201862775486, 10.6526293411458, 
10.1270181743699,
Robin> 10.7479561453406, 10.3223366380115, 10.6640317023258, 
10.8816465650639,
Robin> 10.2469734194448, 11.0595077832844, 10.6211764829084, 
10.8387020014927,
Robin> 10.3842712860829, 10.3288969420998, 11.1095936345021, 
10.7755741380517,
Robin> 10.8891163113089, 10.9239878986268, 10.4674437486482, 
10.4494516106226,
Robin> 10.6816375084280, 10.1609470064992, 10.6055689487767, 
10.3759153410817,
Robin> 10.4743618410399, 10.9932886540585, 10.2563007403496, 
10.0821264920858,
Robin> 10.7293259154111, 10.8834112318584, 10.5285102045021, 
10.7068278466484,
Robin> 10.9517121917501, 10.6249671128484, 10.8188751147001, 
10.5327448695580,
Robin> 10.7315642237059, 10.4996799637132)


>> R.version
Robin> _
Robin> platform   powerpc-apple-darwin8.7.0
Robin> arch   powerpc
Robin> os darwin8.7.0
Robin> system powerpc, darwin8.7.0
Robin> status Under development (unstable)
Robin> major  2
Robin> minor  4.0
Robin> year   2006
Robin> month  07
Robin> day09
Robin> svn rev38523
Robin> language   R
Robin> version.string R version 2.4.0 Under development (unstable)  
Robin> (2006-07-09 r38523)
>> 

Robin> --
Robin> Robin Hankin
Robin> Uncertainty Analyst
Robin> National Oceanography Centre, Southampton
Robin> European Way, Southampton SO14 3ZH, UK
Robin> tel  023-8059-7743

Robin> __
Robin> R-devel@r-project.org mailing list
Robin> 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] Add .git to SCM excludes for build and INSTALL scripts

[Martin Maechler]

Thank you Seth,

I've committed the changes
(BTW: for some reason your patch did not cleanly apply to
build.in).

Regards,
Martin

> "Seth" == Seth Falcon <[EMAIL PROTECTED]>
> on Mon, 10 Jul 2006 12:02:32 -0700 writes:

Seth> Git is a source code management system like CVS, svn, arch, and
Seth> others.  

Seth> It would be nice to add exclude support to R CMD build and INSTALL so
Seth> that the .git subdir of an R package is handled appropriately.

Seth> Here is a possible patch:

[ .]

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

Re: [Rd] invalid alignment error in R-2.4.0

[Robin Hankin]

Hi Martin


On 11 Jul 2006, at 09:25, Martin Maechler wrote:

> I assume this is specific to your installation of R-devel
> (R-2.4.0 "unstable").  If I use your 'out',
>hist(out^4, col = "gray")
> works just fine consistently.
>
> Could it be a compiler / linker mismatch
> on your Mac?  Also, can you run "under the debugger"
>'R -d gdb' (from a commandline) ?
>
> This should allow a traceback ('backtrace', abbreviated 'bt' in "gdb")
> of the C call stack.



transcript follows:


octopus:~/scratch% ./Rd/R.framework/Versions/2.4/Resources/bin/R -d gdb
GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov  2 17:28:16 GMT  
2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
for shared libraries ... done

(gdb) R
Starting program: /Users/rksh/scratch/Rd/R.framework/Versions/2.4/ 
Resources/bin/exec/R
Reading symbols for shared libraries ...+ done

R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
Copyright (C) 2006 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

Reading symbols for shared  
libraries ..  
done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
 > load("~/f")
 > hist(out^4)

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0012
R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
126 vt = v[i + 1];
(gdb) bt
#0  R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
#1  0x0111e5d4 in do_qsort (call=0x1d0ed04, op=0x1, args=0x1d0b7f8,  
rho=0x4) at qsort.c:89
#2  0x010c9a1c in do_internal (call=0x1d0b7f8, op=0x1, args=0x0,  
env=0x1d0c494) at names.c:1091
#3  0x01099bb4 in Rf_eval (e=0x1d0ec94, rho=0x1d0c494) at eval.c:425
#4  0x0109ba10 in do_set (call=0x1d0fb78, op=0x180a390,  
args=0x1d0fb94, rho=0x1d0c494) at eval.c:1337
#5  0x01099bb4 in Rf_eval (e=0x1d0fb78, rho=0x1d0c494) at eval.c:425
#6  0x0109bc60 in do_begin (call=0x1d0fb40, op=0x180a2cc,  
args=0x1d0fb5c, rho=0x1d0c494) at eval.c:1101
#7  0x01099bb4 in Rf_eval (e=0x1d0fb40, rho=0x1d0c494) at eval.c:425
#8  0x01099bb4 in Rf_eval (e=0x1d0fa44, rho=0x1d0c494) at eval.c:425
#9  0x0109ba10 in do_set (call=0x1d0f9f0, op=0x180a390,  
args=0x1d0fa0c, rho=0x1d0c494) at eval.c:1337
#10 0x01099bb4 in Rf_eval (e=0x1d0f9f0, rho=0x1d0c494) at eval.c:425
#11 0x0109bc60 in do_begin (call=0x1d0f5e4, op=0x180a2cc,  
args=0x1d0f9d4, rho=0x1d0c494) at eval.c:1101
#12 0x01099bb4 in Rf_eval (e=0x1d0f5e4, rho=0x1d0c494) at eval.c:425
#13 0x01099bb4 in Rf_eval (e=0x1d0f520, rho=0x1d0c494) at eval.c:425
#14 0x0109bc60 in do_begin (call=0x1d10f18, op=0x180a2cc,  
args=0x1d0f504, rho=0x1d0c494) at eval.c:1101
#15 0x01099bb4 in Rf_eval (e=0x1d10f18, rho=0x1d0c494) at eval.c:425
#16 0x0109d0ac in Rf_applyClosure (call=0x1d1353c, op=0x1d10d58,  
arglist=0x1d0d2ec, rho=0x1d13830, suppliedenv=0x181d304) at eval.c:615
#17 0x01099d94 in Rf_eval (e=0x1d1353c, rho=0x1d13830) at eval.c:456
#18 0x0109b008 in Rf_DispatchOrEval (call=0x1d134cc, op=0x180b978,  
generic=0x11d74d0 "[", args=0x1d13504, rho=0x1d13830, ans=0xbfffa248,  
dropmissing=0, argsevald=0) at eval.c:1758
#19 0x0115a828 in do_subset (call=0x1d134cc, op=0x180b978, args=0x0,  
rho=0x1d13830) at subset.c:527
#20 0x01099bb4 in Rf_eval (e=0x1d134cc, rho=0x1d13830) at eval.c:425
#21 0x01099a5c in Rf_eval (e=0x1d118a0, rho=0x1d1192c) at eval.c:402
#22 0x0109ae04 in Rf_evalList (el=0x1b4f9dc, rho=0x1d1192c) at eval.c: 
1417
#23 0x010c9980 in do_internal (call=0x1b4f9dc, op=0x1,  
args=0x1b4fa14, env=0x1d1192c) at names.c:1087
#24 0x01099bb4 in Rf_eval (e=0x1b4fa30, rho=0x1d1192c) at eval.c:425
#25 0x0109d0ac in Rf_applyClosure (call=0x1d13424, op=0x1b4fa84,  
arglist=0x1d118bc, rho=0x1d13830, suppliedenv=0x181d304) at eval.c:615
#26 0x01099d94 in Rf_eval (e=0x1d13424, rho=0x1d13830) at eval.c:456
#27 0x0109ae7c in Rf_evalList (el=0x1d13408, rho=0x1d13830) at eval.c: 
1427
#28 0x01099c04 in Rf_eval (e=0x1d143b0, rho=0x1d13830) at eval.c:435
#29 0x0109bc60 in do_begin (call=0x1d14378, op=0x180a2cc,  
args=0x1d14394, rho=0x1d13830) at eval.c:1101
#30 0x01099bb4 in Rf_eval (e=0x1d14378, rho

Re: [Rd] invalid alignment error in R-2.4.0

[Martin Maechler]

Hi Robin,

thanks for the extra info.  I have no clue what the problem
might be.

But from R-level debugging (and the R traceback you wrote
originally),
I assume you could trigger the problem already by a simple

  median(rep(1000, 10))

is that the case? If yes, please follow up on R-devel.

In any case, let's wait for others (Mac specialists and/or other
R-core members) to voice ideas.

Martin



> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> on Tue, 11 Jul 2006 10:04:34 +0100 writes:

Robin> Hi Martin
Robin> On 11 Jul 2006, at 09:25, Martin Maechler wrote:

>> I assume this is specific to your installation of R-devel
>> (R-2.4.0 "unstable").  If I use your 'out',
>> hist(out^4, col = "gray")
>> works just fine consistently.
>> 
>> Could it be a compiler / linker mismatch
>> on your Mac?  Also, can you run "under the debugger"
>> 'R -d gdb' (from a commandline) ?
>> 
>> This should allow a traceback ('backtrace', abbreviated 'bt' in "gdb")
>> of the C call stack.



Robin> transcript follows:


Robin> octopus:~/scratch% ./Rd/R.framework/Versions/2.4/Resources/bin/R -d 
gdb
Robin> GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov  2 17:28:16 
GMT  
Robin> 2005)
Robin> Copyright 2004 Free Software Foundation, Inc.
Robin> GDB is free software, covered by the GNU General Public License, and 
 
Robin> you are
Robin> welcome to change it and/or distribute copies of it under certain  
Robin> conditions.
Robin> Type "show copying" to see the conditions.
Robin> There is absolutely no warranty for GDB.  Type "show warranty" for  
Robin> details.
Robin> This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
Robin> for shared libraries ... done

Robin> (gdb) R
Robin> Starting program: /Users/rksh/scratch/Rd/R.framework/Versions/2.4/ 
Robin> Resources/bin/exec/R
Robin> Reading symbols for shared libraries ...+ done

Robin> R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
Robin> Copyright (C) 2006 The R Foundation for Statistical Computing
Robin> ISBN 3-900051-07-0

Robin> R is free software and comes with ABSOLUTELY NO WARRANTY.
Robin> You are welcome to redistribute it under certain conditions.
Robin> Type 'license()' or 'licence()' for distribution details.

Robin> R is a collaborative project with many contributors.
Robin> Type 'contributors()' for more information and
Robin> 'citation()' on how to cite R or R packages in publications.

Robin> Type 'demo()' for some demos, 'help()' for on-line help, or
Robin> 'help.start()' for an HTML browser interface to help.
Robin> Type 'q()' to quit R.

Robin> Reading symbols for shared  
Robin> libraries .. 
 
Robin> done
Robin> Reading symbols for shared libraries . done
Robin> Reading symbols for shared libraries . done
>> load("~/f")
>> hist(out^4)

Robin> Program received signal EXC_BAD_ACCESS, Could not access memory.
Robin> Reason: KERN_PROTECTION_FAILURE at address: 0x0012
Robin> R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
Robin> 126 vt = v[i + 1];
Robin> (gdb) bt
Robin> #0  R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
Robin> #1  0x0111e5d4 in do_qsort (call=0x1d0ed04, op=0x1, args=0x1d0b7f8,  
Robin> rho=0x4) at qsort.c:89
Robin> #2  0x010c9a1c in do_internal (call=0x1d0b7f8, op=0x1, args=0x0,  
Robin> env=0x1d0c494) at names.c:1091
Robin> #3  0x01099bb4 in Rf_eval (e=0x1d0ec94, rho=0x1d0c494) at eval.c:425
Robin> #4  0x0109ba10 in do_set (call=0x1d0fb78, op=0x180a390,  
Robin> args=0x1d0fb94, rho=0x1d0c494) at eval.c:1337
Robin> #5  0x01099bb4 in Rf_eval (e=0x1d0fb78, rho=0x1d0c494) at eval.c:425
Robin> #6  0x0109bc60 in do_begin (call=0x1d0fb40, op=0x180a2cc,  
Robin> args=0x1d0fb5c, rho=0x1d0c494) at eval.c:1101
Robin> #7  0x01099bb4 in Rf_eval (e=0x1d0fb40, rho=0x1d0c494) at eval.c:425
Robin> #8  0x01099bb4 in Rf_eval (e=0x1d0fa44, rho=0x1d0c494) at eval.c:425
Robin> #9  0x0109ba10 in do_set (call=0x1d0f9f0, op=0x180a390,  
Robin> args=0x1d0fa0c, rho=0x1d0c494) at eval.c:1337
Robin> #10 0x01099bb4 in Rf_eval (e=0x1d0f9f0, rho=0x1d0c494) at eval.c:425
Robin> #11 0x0109bc60 in do_begin (call=0x1d0f5e4, op=0x180a2cc,  
Robin> args=0x1d0f9d4, rho=0x1d0c494) at eval.c:1101
Robin> #12 0x01099bb4 in Rf_eval (e=0x1d0f5e4, rho=0x1d0c494) at eval.c:425
Robin> #13 0x01099bb4 in Rf_eval (e=0x1d0f520, rho=0x1d0c494) at eval.c:425
Robin> #14 0x0109bc60 in do_begin (call=0x1d10f18, op=0x180a2cc,  
Robin> args=0x1d0f504, rho=0x1d0c494) at eval.c:1101
Robin> #15 0x01099bb4 in Rf_eval (e=0x1d10f18, rho=0x1d0c494) at eval.c:425
Robin> #16 0x0109d0ac in Rf_applyClosure (call=0x1d1353c, op=0x1d10d58,  
Robin> arglist=0x1d

Re: [Rd] invalid alignment error in R-2.4.0

[Prof Brian Ripley]

On Tue, 11 Jul 2006, Martin Maechler wrote:

> Hi Robin,
> 
> thanks for the extra info.  I have no clue what the problem
> might be.
> 
> But from R-level debugging (and the R traceback you wrote
> originally),
> I assume you could trigger the problem already by a simple
> 
>   median(rep(1000, 10))
> 
> is that the case? If yes, please follow up on R-devel.

I don't see why you assume so: there are multitudinous paths through 
qsort.

> In any case, let's wait for others (Mac specialists and/or other
> R-core members) to voice ideas.

I checked this under valgrind, which normally shows up such errors, and 
found nothing, even with gctorture on (and valgrind instrumentation of 
R's memory management on).

You used the dput and Robin used load(), so presumably on not exactly the 
same object.  I think Robin needs to test what he actually gave us, to be 
sure.  If that is the case, I suspect the compiler.

> 
> Martin
> 
> 
> 
> > "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> > on Tue, 11 Jul 2006 10:04:34 +0100 writes:
> 
> Robin> Hi Martin
> Robin> On 11 Jul 2006, at 09:25, Martin Maechler wrote:
> 
> >> I assume this is specific to your installation of R-devel
> >> (R-2.4.0 "unstable").  If I use your 'out',
> >> hist(out^4, col = "gray")
> >> works just fine consistently.
> >> 
> >> Could it be a compiler / linker mismatch
> >> on your Mac?  Also, can you run "under the debugger"
> >> 'R -d gdb' (from a commandline) ?
> >> 
> >> This should allow a traceback ('backtrace', abbreviated 'bt' in "gdb")
> >> of the C call stack.
> 
> 
> 
> Robin> transcript follows:
> 
> 
> Robin> octopus:~/scratch% ./Rd/R.framework/Versions/2.4/Resources/bin/R 
> -d gdb
> Robin> GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov  2 17:28:16 
> GMT  
> Robin> 2005)
> Robin> Copyright 2004 Free Software Foundation, Inc.
> Robin> GDB is free software, covered by the GNU General Public License, 
> and  
> Robin> you are
> Robin> welcome to change it and/or distribute copies of it under certain  
> Robin> conditions.
> Robin> Type "show copying" to see the conditions.
> Robin> There is absolutely no warranty for GDB.  Type "show warranty" for 
>  
> Robin> details.
> Robin> This GDB was configured as "powerpc-apple-darwin"...Reading 
> symbols  
> Robin> for shared libraries ... done
> 
> Robin> (gdb) R
> Robin> Starting program: /Users/rksh/scratch/Rd/R.framework/Versions/2.4/ 
> Robin> Resources/bin/exec/R
> Robin> Reading symbols for shared libraries ...+ done
> 
> Robin> R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
> Robin> Copyright (C) 2006 The R Foundation for Statistical Computing
> Robin> ISBN 3-900051-07-0
> 
> Robin> R is free software and comes with ABSOLUTELY NO WARRANTY.
> Robin> You are welcome to redistribute it under certain conditions.
> Robin> Type 'license()' or 'licence()' for distribution details.
> 
> Robin> R is a collaborative project with many contributors.
> Robin> Type 'contributors()' for more information and
> Robin> 'citation()' on how to cite R or R packages in publications.
> 
> Robin> Type 'demo()' for some demos, 'help()' for on-line help, or
> Robin> 'help.start()' for an HTML browser interface to help.
> Robin> Type 'q()' to quit R.
> 
> Robin> Reading symbols for shared  
> Robin> libraries 
> ..  
> Robin> done
> Robin> Reading symbols for shared libraries . done
> Robin> Reading symbols for shared libraries . done
> >> load("~/f")
> >> hist(out^4)
> 
> Robin> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Robin> Reason: KERN_PROTECTION_FAILURE at address: 0x0012
> Robin> R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
> Robin> 126 vt = v[i + 1];
> Robin> (gdb) bt
> Robin> #0  R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
> Robin> #1  0x0111e5d4 in do_qsort (call=0x1d0ed04, op=0x1, 
> args=0x1d0b7f8,  
> Robin> rho=0x4) at qsort.c:89
> Robin> #2  0x010c9a1c in do_internal (call=0x1d0b7f8, op=0x1, args=0x0,  
> Robin> env=0x1d0c494) at names.c:1091
> Robin> #3  0x01099bb4 in Rf_eval (e=0x1d0ec94, rho=0x1d0c494) at 
> eval.c:425
> Robin> #4  0x0109ba10 in do_set (call=0x1d0fb78, op=0x180a390,  
> Robin> args=0x1d0fb94, rho=0x1d0c494) at eval.c:1337
> Robin> #5  0x01099bb4 in Rf_eval (e=0x1d0fb78, rho=0x1d0c494) at 
> eval.c:425
> Robin> #6  0x0109bc60 in do_begin (call=0x1d0fb40, op=0x180a2cc,  
> Robin> args=0x1d0fb5c, rho=0x1d0c494) at eval.c:1101
> Robin> #7  0x01099bb4 in Rf_eval (e=0x1d0fb40, rho=0x1d0c494) at 
> eval.c:425
> Robin> #8  0x01099bb4 in Rf_eval (e=0x1d0fa44, rho=0x1d0c494) at 
> eval.c:425
> Robin> #9  0x0109ba10 in do_set (call=0x1d0f9f0, op=0x180a390,

Re: [Rd] invalid alignment error in R-2.4.0

[Martin Maechler]

> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Tue, 11 Jul 2006 10:54:15 +0100 (BST) writes:

BDR> On Tue, 11 Jul 2006, Martin Maechler wrote:
>> Hi Robin,
>> 
>> thanks for the extra info.  I have no clue what the problem
>> might be.
>> 
>> But from R-level debugging (and the R traceback you wrote
>> originally),
>> I assume you could trigger the problem already by a simple
>> 
>> median(rep(1000, 10))
>> 
>> is that the case? If yes, please follow up on R-devel.

BDR> I don't see why you assume so: 
BDR> there are multitudinous paths through  qsort.

yes, but I had Robin's data (*) and used debug(hist.default) :
diff(breaks) *was* identical to rep(1000, 10)  for the data
Robin posted.

>> In any case, let's wait for others (Mac specialists and/or other
>> R-core members) to voice ideas.

BDR> I checked this under valgrind, which normally shows up such errors, 
and 
BDR> found nothing, even with gctorture on (and valgrind instrumentation of 
BDR> R's memory management on).

BDR> You used the dput and Robin used load(), so presumably on not exactly 
the 
BDR> same object.  


ahh yes, good point...
(*) hence means I only had the dput() version of his data.

BDR> I think Robin needs to test what he actually gave us, to be 
BDR> sure.  If that is the case, I suspect the compiler.



>> Martin
>> 
>> 
>> 
>> > "Robin" == Robin Hankin <[EMAIL PROTECTED]>
>> > on Tue, 11 Jul 2006 10:04:34 +0100 writes:
>> 
Robin> Hi Martin
Robin> On 11 Jul 2006, at 09:25, Martin Maechler wrote:
>> 
>> >> I assume this is specific to your installation of R-devel
>> >> (R-2.4.0 "unstable").  If I use your 'out',
>> >> hist(out^4, col = "gray")
>> >> works just fine consistently.
>> >> 
>> >> Could it be a compiler / linker mismatch
>> >> on your Mac?  Also, can you run "under the debugger"
>> >> 'R -d gdb' (from a commandline) ?
>> >> 
>> >> This should allow a traceback ('backtrace', abbreviated 'bt' in "gdb")
>> >> of the C call stack.
>> 
>> 
>> 
Robin> transcript follows:
>> 
>> 
Robin> octopus:~/scratch% ./Rd/R.framework/Versions/2.4/Resources/bin/R -d 
gdb
Robin> GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov  2 17:28:16 
GMT  
Robin> 2005)
Robin> Copyright 2004 Free Software Foundation, Inc.
Robin> GDB is free software, covered by the GNU General Public License, and 
 
Robin> you are
Robin> welcome to change it and/or distribute copies of it under certain  
Robin> conditions.
Robin> Type "show copying" to see the conditions.
Robin> There is absolutely no warranty for GDB.  Type "show warranty" for  
Robin> details.
Robin> This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
Robin> for shared libraries ... done
>> 
Robin> (gdb) R
Robin> Starting program: /Users/rksh/scratch/Rd/R.framework/Versions/2.4/ 
Robin> Resources/bin/exec/R
Robin> Reading symbols for shared libraries ...+ done
>> 
Robin> R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
Robin> Copyright (C) 2006 The R Foundation for Statistical Computing
Robin> ISBN 3-900051-07-0
>> 
Robin> R is free software and comes with ABSOLUTELY NO WARRANTY.
Robin> You are welcome to redistribute it under certain conditions.
Robin> Type 'license()' or 'licence()' for distribution details.
>> 
Robin> R is a collaborative project with many contributors.
Robin> Type 'contributors()' for more information and
Robin> 'citation()' on how to cite R or R packages in publications.
>> 
Robin> Type 'demo()' for some demos, 'help()' for on-line help, or
Robin> 'help.start()' for an HTML browser interface to help.
Robin> Type 'q()' to quit R.
>> 
Robin> Reading symbols for shared  
Robin> libraries .. 
 
Robin> done
Robin> Reading symbols for shared libraries . done
Robin> Reading symbols for shared libraries . done
>> >> load("~/f")
>> >> hist(out^4)
>> 
Robin> Program received signal EXC_BAD_ACCESS, Could not access memory.
Robin> Reason: KERN_PROTECTION_FAILURE at address: 0x0012
Robin> R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
Robin> 126 vt = v[i + 1];
Robin> (gdb) bt
Robin> #0  R_qsort (v=0x2855858, i=1, j=2) at qsort-body.c:126
Robin> #1  0x0111e5d4 in do_qsort (call=0x1d0ed04, op=0x1, args=0x1d0b7f8,  
Robin> rho=0x4) at qsort.c:89
Robin> #2  0x010c9a1c in do_internal (call=0x1d0b7f8, op=0x1, args=0x0,  
Robin> env=0x1d0c494) at names.c:1091
Robin> #3  0x01099bb4 in Rf_eval (e=0x1d0ec94, rho=0x1d0c494) at eval.c:425
Robin> #4  0x0109ba10 in do_set (call=0x1d0fb78, op=0x180a390,  
Robin> args=0x1d0fb

Re: [Rd] invalid alignment error in R-2.4.0

[Robin Hankin]

Hi

median(rep(1000,10)) does indeed give a similar error:


octopus:~/scratch% ./Rd/R.framework/Versions/2.4/Resources/bin/R -d gdb
GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov  2 17:28:16 GMT  
2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
for shared libraries ... done

(gdb) R
Starting program: /Users/rksh/scratch/Rd/R.framework/Versions/2.4/ 
Resources/bin/exec/R
Reading symbols for shared libraries ...+ done

R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
Copyright (C) 2006 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

Reading symbols for shared  
libraries ..  
done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
 > median(rep(1000,10))

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0012
R_qsort (v=0x2891c70, i=1, j=2) at qsort-body.c:126
126 vt = v[i + 1];
(gdb) bt
#0  R_qsort (v=0x2891c70, i=1, j=2) at qsort-body.c:126
#1  0x0111e5d4 in do_qsort (call=0x1d365d4, op=0x1, args=0x1d31de4,  
rho=0x4) at qsort.c:89
#2  0x010c9a1c in do_internal (call=0x1d31de4, op=0x1, args=0x0,  
env=0x1d331f0) at names.c:1091
#3  0x01099bb4 in Rf_eval (e=0x1d3659c, rho=0x1d331f0) at eval.c:425
#4  0x0109ba10 in do_set (call=0x1d36548, op=0x180a390,  
args=0x1d36564, rho=0x1d331f0) at eval.c:1337
#5  0x01099bb4 in Rf_eval (e=0x1d36548, rho=0x1d331f0) at eval.c:425
#6  0x0109bc60 in do_begin (call=0x1d36510, op=0x180a2cc,  
args=0x1d3652c, rho=0x1d331f0) at eval.c:1101
#7  0x01099bb4 in Rf_eval (e=0x1d36510, rho=0x1d331f0) at eval.c:425
#8  0x01099bb4 in Rf_eval (e=0x1d363c0, rho=0x1d331f0) at eval.c:425
#9  0x0109ba10 in do_set (call=0x1d3636c, op=0x180a390,  
args=0x1d36388, rho=0x1d331f0) at eval.c:1337
#10 0x01099bb4 in Rf_eval (e=0x1d3636c, rho=0x1d331f0) at eval.c:425
#11 0x0109bc60 in do_begin (call=0x1d36e44, op=0x180a2cc,  
args=0x1d36350, rho=0x1d331f0) at eval.c:1101
#12 0x01099bb4 in Rf_eval (e=0x1d36e44, rho=0x1d331f0) at eval.c:425
#13 0x01099bb4 in Rf_eval (e=0x1d36d80, rho=0x1d331f0) at eval.c:425
#14 0x0109bc60 in do_begin (call=0x1d385b8, op=0x180a2cc,  
args=0x1d36d48, rho=0x1d331f0) at eval.c:1101
#15 0x01099bb4 in Rf_eval (e=0x1d385b8, rho=0x1d331f0) at eval.c:425
#16 0x0109d0ac in Rf_applyClosure (call=0x1d3d6d0, op=0x1d38318,  
arglist=0x1d330bc, rho=0x1d3ca54, suppliedenv=0x181d304) at eval.c:615
#17 0x01099d94 in Rf_eval (e=0x1d3d6d0, rho=0x1d3ca54) at eval.c:456
#18 0x0109b008 in Rf_DispatchOrEval (call=0x1d3d698, op=0x180b978,  
generic=0x11d74d0 "[", args=0x1d3d6b4, rho=0x1d3ca54, ans=0xbfffc0f8,  
dropmissing=0, argsevald=0) at eval.c:1758
#19 0x0115a828 in do_subset (call=0x1d3d698, op=0x180b978, args=0x0,  
rho=0x1d3ca54) at subset.c:527
#20 0x01099bb4 in Rf_eval (e=0x1d3d698, rho=0x1d3ca54) at eval.c:425
#21 0x01099a5c in Rf_eval (e=0x1d38f5c, rho=0x1d38024) at eval.c:402
#22 0x0109ae04 in Rf_evalList (el=0x1b4f9dc, rho=0x1d38024) at eval.c: 
1417
#23 0x010c9980 in do_internal (call=0x1b4f9dc, op=0x1,  
args=0x1b4fa14, env=0x1d38024) at names.c:1087
#24 0x01099bb4 in Rf_eval (e=0x1b4fa30, rho=0x1d38024) at eval.c:425
#25 0x0109d0ac in Rf_applyClosure (call=0x1d3d660, op=0x1b4fa84,  
arglist=0x1d38f78, rho=0x1d3ca54, suppliedenv=0x181d304) at eval.c:615
#26 0x01099d94 in Rf_eval (e=0x1d3d660, rho=0x1d3ca54) at eval.c:456
#27 0x0109ae7c in Rf_evalList (el=0x1d3d644, rho=0x1d3ca54) at eval.c: 
1427
#28 0x01099c04 in Rf_eval (e=0x1d3d628, rho=0x1d3ca54) at eval.c:435
#29 0x0109bc60 in do_begin (call=0x1d3d5f0, op=0x180a2cc,  
args=0x1d3d60c, rho=0x1d3ca54) at eval.c:1101
#30 0x01099bb4 in Rf_eval (e=0x1d3d5f0, rho=0x1d3ca54) at eval.c:425
#31 0x01099bb4 in Rf_eval (e=0x1d3d2c4, rho=0x1d3ca54) at eval.c:425
#32 0x0109bc60 in do_begin (call=0x1d3dc24, op=0x180a2cc,  
args=0x1d3d2a8, rho=0x1d3ca54) at eval.c:1101
#33 0x01099bb4 in Rf_eval (e=0x1d3dc24, rho=0x1d3ca54) at eval.c:425
#34 0x0109d0ac in Rf_applyClosure (call=0x1d3ee00, op=0x1d3f0a0,  
arglist=0x1d3ca00, rho=0x181d2e8, suppliedenv=0x181d304) at eval.c:615
#35 0x01099d94 in Rf_eval (e=0

Re: [Rd] often unnecessary duplicate in sapply / as.vector

[Prof Brian Ripley]

On Fri, 7 Jul 2006, Thomas Lumley wrote:

> On Fri, 7 Jul 2006, Martin Morgan wrote:
> 
> > sapply calls lapply as
> >
> >answer <- lapply(as.list(X), FUN, ...)
> >
> > which, when X is a list, causes X to be duplicated unnecessarily. The
> > coercion is unnecessary for other mode(X) because in lapply we have
> >
> >if (!is.list(X)) X <- as.list(X)
> 
> That looks reasonable.

And you have made the change.  Unfortunately it is not really reasonable, 
as is.list(X) does not test that X is a list (see its documentation) in 
the same sense as as.list, so pairlists are now passed to the internal 
code.

There's something rather undesirable going on here.  The internal code for 
lapply (in its current version, not the one I wrote) does the internal 
equivalent of

rval <- vector("list", length(X))
for(i in seq(along = X))
rval[i] <- list(FUN(X[[i]], ...))

from the earlier

lapply <- function(X, FUN, ...) {
FUN <- match.fun(FUN)
if (!is.list(X))
X <- as.list(X)
rval <- vector("list", length(X))
for(i in seq(along = X))
rval[i] <- list(FUN(X[[i]], ...))
names(rval) <- names(X)   # keep `names' !
return(rval)
}

so all that is needed is that X[[i]] work.

For a pairlist [[i]] done repeatedly is very inefficient (since it starts 
at the beginning each time), so we *do* want to coerce pairlists here.

On the other hand, we do not need to coerce expressions or atomic vectors 
for which [[]] works just fine.

> > More generally, perhaps as.vector might not duplicate when mode(x) == mode ?
> 
> This isn't a trivial change, because  mode(x)==mode does not guarantee 
> that as.vector(x, mode) has no effect.  For example, with mode="numeric" it 
> removes attributes.

And with mode="list" it does not (although that is not as documented).
We can certainly do better.  [This is another of those cases where 'mode' 
is confusing, and in fact it would be typeof(x) == mode.]

However, for now let us concentrate on as.list.default, which does

as.list.default <- function (x, ...)
{
if (is.function(x))
return(c(formals(x), list(body(x
if (is.expression(x)) {
n <- length(x)
l <- vector("list", n)
i <- 0
for (sub in x) l[[i <- i + 1]] <- sub
return(l)
}
.Internal(as.vector(x, "list"))
}

That's a bit strange, as an expression is internally a list, and it loses 
the names on the expression.  I intend to make as.list(x) return 
x unchanged if x is a list (not a pairlist), and to coerce expressions 
internally.

After that I will think about making as.vector and lapply make fewer 
copies.

-- 
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] Add .git to SCM excludes for build and INSTALL scripts

[Seth Falcon]

Martin Maechler <[EMAIL PROTECTED]> writes:
> I've committed the changes
> (BTW: for some reason your patch did not cleanly apply to
> build.in).

Thanks!  Sorry about the bad patch, not sure what happened; next time
around I will try harder to send something usable.

Best,

+ seth

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

[Rd] Sweave processes comments incorrectly (PR#9073)

[krc]

Full_Name: Kevin R. Coombes
Version: 2.1.0
OS: Windows XP
Submission from: (NULL) (143.111.22.24)


I have a source file "devel.Rnw" that uses the LaTeX foils class and ppower4 to
produce a PDF presentation file.  It starts with a commented note to myself as
follows:

 begin source example 
%
%  Remember to update the hypersetup to include individual lecture
%  titles, change the leftheader to include the lecture title, and
%  then start at \begin{document} 
%  Also, produce a printable (black and white version) according
%  to the cues immediately following \begin{document}.
%  Compile this document with:
%pdflatex .tex
%  and then:
%ppower4pb .pdf .pdf
%
\documentclass[Screen4to3,25pt,headrule,footrule]{foils}
\usepackage[pdftex]{color}  %for colors
\definecolor{Teal}{rgb}{0.0,0.47,0.46}
%% more colors and packages omitted from bug report
\begin{document}
\hypersetup{pdfpagetransition=Replace}

 end source example 

When processed using Sweave, the \begin{document} comments are expanded to
actual LaTeX commands, causing a later latex to fail.  That is, the output of
running Sweave() on this file begins:

 begin source example 
%
%  Remember to update the hypersetup to include individual lecture
%  titles, change the leftheader to include the lecture title, and
%  then start at \usepackage{c:/R/rw2010/share/texmf/Sweave}
\begin{document} 
%  Also, produce a printable (black and white version) according
%  to the cues immediately following
\usepackage{c:/R/rw2010/share/texmf/Sweave}
\begin{document}.
%  Compile this document with:
%pdflatex .tex
%  and then:
%ppower4pb .pdf .pdf
\documentclass[Screen4to3,25pt,headrule,footrule]{foils}
\usepackage[pdftex]{color}  %for colors

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

Re: [Rd] often unnecessary duplicate in sapply / as.vector

[Thomas Lumley]

On Tue, 11 Jul 2006, Prof Brian Ripley wrote:

> On Fri, 7 Jul 2006, Thomas Lumley wrote:
>
>> On Fri, 7 Jul 2006, Martin Morgan wrote:
>>
>>> sapply calls lapply as
>>>
>>>answer <- lapply(as.list(X), FUN, ...)
>>>
>>> which, when X is a list, causes X to be duplicated unnecessarily. The
>>> coercion is unnecessary for other mode(X) because in lapply we have
>>>
>>>if (!is.list(X)) X <- as.list(X)
>>
>> That looks reasonable.
>
> And you have made the change.  Unfortunately it is not really reasonable,
> as is.list(X) does not test that X is a list (see its documentation) in
> the same sense as as.list, so pairlists are now passed to the internal
> code.

Where do we still get pairlists in interpreted code? I thought they had 
all been hidden.

> There's something rather undesirable going on here.  The internal code for
> lapply (in its current version, not the one I wrote) does the internal
> equivalent of
>
>rval <- vector("list", length(X))
>for(i in seq(along = X))
>rval[i] <- list(FUN(X[[i]], ...))
>
> from the earlier
>
> lapply <- function(X, FUN, ...) {
>FUN <- match.fun(FUN)
>if (!is.list(X))
>X <- as.list(X)
>rval <- vector("list", length(X))
>for(i in seq(along = X))
>rval[i] <- list(FUN(X[[i]], ...))
>names(rval) <- names(X)   # keep `names' !
>return(rval)
> }
>
> so all that is needed is that X[[i]] work.
>
> For a pairlist [[i]] done repeatedly is very inefficient (since it starts
> at the beginning each time), so we *do* want to coerce pairlists here.

Or have a separate loop using CDR and CAR rather than [[, which would mean 
not having to copy X.


> On the other hand, we do not need to coerce expressions or atomic vectors
> for which [[]] works just fine.

Indeed.

-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] often unnecessary duplicate in sapply / as.vector

[Prof Brian Ripley]

On Tue, 11 Jul 2006, Thomas Lumley wrote:

> On Tue, 11 Jul 2006, Prof Brian Ripley wrote:
> 
> > On Fri, 7 Jul 2006, Thomas Lumley wrote:
> >
> > > On Fri, 7 Jul 2006, Martin Morgan wrote:
> > >
> > > > sapply calls lapply as
> > > >
> > > >answer <- lapply(as.list(X), FUN, ...)
> > > >
> > > > which, when X is a list, causes X to be duplicated unnecessarily. The
> > > > coercion is unnecessary for other mode(X) because in lapply we have
> > > >
> > > >if (!is.list(X)) X <- as.list(X)
> > >
> > > That looks reasonable.
> >
> > And you have made the change.  Unfortunately it is not really reasonable,
> > as is.list(X) does not test that X is a list (see its documentation) in
> > the same sense as as.list, so pairlists are now passed to the internal
> > code.
> 
> Where do we still get pairlists in interpreted code? I thought they had all
> been hidden.

Not quite all.  You can use pairlist() to create them, and .Options is one 
(fairly long) example.  (I used pairlist to create a very slow example.)

> > There's something rather undesirable going on here.  The internal code for
> > lapply (in its current version, not the one I wrote) does the internal
> > equivalent of
> >
> >rval <- vector("list", length(X))
> >for(i in seq(along = X))
> >rval[i] <- list(FUN(X[[i]], ...))
> >
> > from the earlier
> >
> > lapply <- function(X, FUN, ...) {
> >FUN <- match.fun(FUN)
> >if (!is.list(X))
> >X <- as.list(X)
> >rval <- vector("list", length(X))
> >for(i in seq(along = X))
> >rval[i] <- list(FUN(X[[i]], ...))
> >names(rval) <- names(X)   # keep `names' !
> >return(rval)
> > }
> >
> > so all that is needed is that X[[i]] work.
> >
> > For a pairlist [[i]] done repeatedly is very inefficient (since it starts
> > at the beginning each time), so we *do* want to coerce pairlists here.
> 
> Or have a separate loop using CDR and CAR rather than [[, which would mean not
> having to copy X.

If we are going there we should also special-case all the (much more 
common) vector types thereby avoiding [[, which I have so far resisted.

> > On the other hand, we do not need to coerce expressions or atomic vectors
> > for which [[]] works just fine.
> 
> Indeed.

I've just committed a version that is a lot faster, fast enough to shave 
5% off the total time for both the stats and boot examples.

-- 
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] RcppTemplate 4.0 with data frame support

[Dominick Samperi]

Data frame support has been added to the package
RcppTemplate 4.0, a template/class library that facilitates the
use of C++ libraries from R.

On the C++ side the code might look something like:

RcppFrame frame(fp); // Here fp is the input SEXP corresponding to an R 
data frame.
vector > table = frame.getTableData();
...
level = table[row][col].getFactorLevel();
name = table[row][col].getFactorName();
...

Thanks to Hin-Tak Leung and other users of this mailing list for
helpful comments.

The RcppTemplate package also contains detailed instructions on
using MinGW and MS Visual C++ under Windows.

ds

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

Re: [Rd] [R] Date Format

[Martyn Plummer]

I moved this to R-devel because I am wondering why the base package does
not allow you to convert from numeric to Date. Could we not have
something like this?

as.Date.numeric <- function(x, epoch="1970-01-01", ...) {
   if (!is.character(epoch) || length(epoch) != 1)
  stop("invalid epoch")
   as.Date(epoch, ...) + x
}

Martyn

On Tue, 2006-07-11 at 12:58 -0400, Gabor Grothendieck wrote:
> Try this:
> 
> library(zoo)
> as.Date(11328)
> 
> See the Help Desk article in R News 4/1 for more on dates.
> 
> 
> On 7/11/06, pierre clauss <[EMAIL PROTECTED]> wrote:
> > Hi everybody,
> > I need your precious help for, I think, a simple request, but I do not 
> > manage to solve this.
> >
> > When I use a "table" function with dates in the rows, the rows are coerced 
> > to number after the table function.
> >
> > So I need to transform the row names into date format. But I do not manage.
> >
> > Therefore, for an example, I manage to write this :
> >
> > datetest<-"06/01/2001"
> > datetest<-as.Date(datetest,"%d/%m/%Y")
> > datetest<-as.numeric(datetest)
> >
> > to get 11328.
> >
> > But I do not obtain the inverse tranformation :
> >
> > datetest<-as.Date(datetest,"%d/%m/%Y")
> >
> > How do we get this please ?
> >
> > Thanks a lot for your solution.
> > Pierre.
> >
> >

---
This message and its attachments are strictly confidential. ...{{dropped}}

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

Re: [Rd] [R] Date Format

[Peter Dalgaard]

Martyn Plummer <[EMAIL PROTECTED]> writes:

> I moved this to R-devel because I am wondering why the base package does
> not allow you to convert from numeric to Date. Could we not have
> something like this?
> 
> as.Date.numeric <- function(x, epoch="1970-01-01", ...) {
>if (!is.character(epoch) || length(epoch) != 1)
>   stop("invalid epoch")
>as.Date(epoch, ...) + x
> }

We could, but you might as well do it explicitly. There's something to
be said for not confusing the concept of dates with a particular
implementation, which is effectively what happens if you can convert
them to and from numeric too seamlessly.

I'm more perplexed by the failure of adding difftimes to dates:

> as.Date("2006-1-1") + (as.Date("2006-1-1") - as.Date("2006-1-2"))
[1] "2005-12-31"
Warning message:
Incompatible methods ("+.Date", "Ops.difftime") for "+"

and if you have a difftime in non-days units, you'll  actually get a
wrong result:

> D1 <- as.Date("2006-1-1")
> D2 <- as.Date("2006-1-2")
> difftime(D2,D1,units="hours")
Time difference of 24 hours
> dd <- difftime(D2,D1,units="hours")
> D1+dd
[1] "2006-01-25"
Warning message:
Incompatible methods ("+.Date", "Ops.difftime") for "+"




> On Tue, 2006-07-11 at 12:58 -0400, Gabor Grothendieck wrote:
> > Try this:
> > 
> > library(zoo)
> > as.Date(11328)
> > 
> > See the Help Desk article in R News 4/1 for more on dates.
> > 
> > 
> > On 7/11/06, pierre clauss <[EMAIL PROTECTED]> wrote:
> > > Hi everybody,
> > > I need your precious help for, I think, a simple request, but I do not 
> > > manage to solve this.
> > >
> > > When I use a "table" function with dates in the rows, the rows are 
> > > coerced to number after the table function.
> > >
> > > So I need to transform the row names into date format. But I do not 
> > > manage.
> > >
> > > Therefore, for an example, I manage to write this :
> > >
> > > datetest<-"06/01/2001"
> > > datetest<-as.Date(datetest,"%d/%m/%Y")
> > > datetest<-as.numeric(datetest)
> > >
> > > to get 11328.
> > >
> > > But I do not obtain the inverse tranformation :
> > >
> > > datetest<-as.Date(datetest,"%d/%m/%Y")
> > >
> > > How do we get this please ?
> > >
> > > Thanks a lot for your solution.
> > > Pierre.
> > >
> > >
> 
> ---
> This message and its attachments are strictly confidential. ...{{dropped}}
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

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

[Rd] Shared Library Support for AIX?

[Matthew Beason]

Fellow R Enthusiasts,

I noted on the "R Installation and Administration" page, section C.9
that "--enable-R-shlib" is reported not to work for AIX. Has anyone made
any further progress with this as of late? I've successfully compiled R
2.3.1 on AIX 5.2ML7 and AIX 5.3ML3. However, I'd really like to use
RSPerl so I can attack R with Perl. Is there a way to do this without
shared libraries enabled? 

Any thoughts, advice, pointers would be greatly appreciated. 

Matthew Beason
Analyst - Capacity Planning
Harrah's Entertainment, Inc.
One Harrah's Court, Las Vegas, NV 89119-4312
Office: 702-494-4097
Mobile: 702-622-6902
[EMAIL PROTECTED]
The information contained in this email may be legally privileged and
confidential. It is intended to be read only by the person to whom it is
addressed. If you have received this in error or are not the intended
recipient, please immediately notify the sender and delete all copies of
this message. Thank you.



[[alternative HTML version deleted]]

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

[Rd] Converting SEXP to primitive C types

[Michael Petrovich]

I'm new to R development, so this may be a trivial question.

In C, How do you convert a SEXP value returned by an R function to a  
primitive C type (int, double, char, array, etc.)? I've tried using  
the INTEGER(x), VECTOR_ELT(x,i), and similar functions found in /src/ 
include/Rinternals.h, but doing so results in incorrect results or a  
seg-fault.

For example, I modified /tests/Embedding/Rerror.c so that it tries to  
print the value returned by the function defined in error.R:

val = Test_tryEval(e, &errorOccurred);
printf("Returned: {%d}\n", VECTOR_ELT(val, 0) );

Where error.R is contains:

foo <-
function(x=3, y=6)
{
   z <- x * y
   z
}

But the output is just "0", not the correct "18". Any ideas?

Thanks for your help!

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

Re: [Rd] Converting SEXP to primitive C types

[Prof Brian Ripley]

On Tue, 11 Jul 2006, Michael Petrovich wrote:

> I'm new to R development, so this may be a trivial question.
> 
> In C, How do you convert a SEXP value returned by an R function to a  
> primitive C type (int, double, char, array, etc.)? I've tried using  
> the INTEGER(x), VECTOR_ELT(x,i), and similar functions found in /src/ 
> include/Rinternals.h, but doing so results in incorrect results or a  
> seg-fault.

See `Writing R Extensions', the documentation for that file.  You cannot 
just guess that an object has the appropriate SEXPTYPE: you have to check 
it (or coerce to it).  In your example it is likely to be a REALSXP (it 
could be an INTSXP), so you need to cover all possible cases.

> For example, I modified /tests/Embedding/Rerror.c so that it tries to  
> print the value returned by the function defined in error.R:
> 
> val = Test_tryEval(e, &errorOccurred);
> printf("Returned: {%d}\n", VECTOR_ELT(val, 0) );
> 
> Where error.R is contains:
> 
> foo <-
> function(x=3, y=6)
> {
>z <- x * y
>z
> }
> 
> But the output is just "0", not the correct "18". Any ideas?
> 
> Thanks for your help!


-- 
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] often unnecessary duplicate in sapply / as.vector

[Prof Brian Ripley]

On Tue, 11 Jul 2006, Prof Brian Ripley wrote:

> On Fri, 7 Jul 2006, Thomas Lumley wrote:

> > On Fri, 7 Jul 2006, Martin Morgan wrote:

[...]

> > > More generally, perhaps as.vector might not duplicate when mode(x) == 
> > > mode ?
> > 
> > This isn't a trivial change, because  mode(x)==mode does not guarantee 
> > that as.vector(x, mode) has no effect.  For example, with mode="numeric" it 
> > removes attributes.
> 
> And with mode="list" it does not (although that is not as documented).
> We can certainly do better.  [This is another of those cases where 'mode' 
> is confusing, and in fact it would be typeof(x) == mode.]

Aargh: of course I should have guessed that quite a few people have 
written code that assumes that e.g. as.double() duplicates.  The first I 
came across is a .Fortran call in smooth.spline with DUP=FALSE which 
despite all the warnings changes its 'w' argument and hence the return 
result from smooth.spline if as.double is made more efficient.

I really have no desire to spend any more time tracking down problems 
caused by such rogue code, so I am going to leave this as is (with as.list 
somewhat more efficient but the as.vector functions always duplicating).

-- 
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] Dropping unused levels of a factor that has "NA" as a level

[J. Hosking]

Is this a bug?

   > f1 <- factor(c("a", NA), levels = c("a", "NA") )
   > f2 <- f1[, drop = TRUE]
   > f2
   [1] a
   Levels: a 

I would have expected f2 to have only one level, "a".  It seems
to me that the code in [.factor does not follow the advice in
help("factor") on how to set factor codes to be missing when
"NA" is a level of the factor.


J. R. M. Hosking

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

Re: [Rd] often unnecessary duplicate in sapply / as.vector

[Martin Morgan]

This is because RObjToCPtr is not quite careful enough with NAMED,
rather than an issue with as.XXX

tmp.c: void tmp(double *x) { x[0]=1; return; }

> f <- function(x) x
> x <- 0
> .C("tmp", f(x), DUP=FALSE)
[[1]]
[1] 1

> x
[1] 1

> x <- 0
> y <- x
> .C("tmp", x, DUP=FALSE)
[[1]]
[1] 1

> y
[1] 1

Martin

Prof Brian Ripley <[EMAIL PROTECTED]> writes:

> On Tue, 11 Jul 2006, Prof Brian Ripley wrote:
>
>> On Fri, 7 Jul 2006, Thomas Lumley wrote:
>
>> > On Fri, 7 Jul 2006, Martin Morgan wrote:
>
> [...]
>
>> > > More generally, perhaps as.vector might not duplicate when mode(x) == 
>> > > mode ?
>> > 
>> > This isn't a trivial change, because  mode(x)==mode does not guarantee 
>> > that as.vector(x, mode) has no effect.  For example, with mode="numeric" 
>> > it 
>> > removes attributes.
>> 
>> And with mode="list" it does not (although that is not as documented).
>> We can certainly do better.  [This is another of those cases where 'mode' 
>> is confusing, and in fact it would be typeof(x) == mode.]
>
> Aargh: of course I should have guessed that quite a few people have 
> written code that assumes that e.g. as.double() duplicates.  The first I 
> came across is a .Fortran call in smooth.spline with DUP=FALSE which 
> despite all the warnings changes its 'w' argument and hence the return 
> result from smooth.spline if as.double is made more efficient.
>
> I really have no desire to spend any more time tracking down problems 
> caused by such rogue code, so I am going to leave this as is (with as.list 
> somewhat more efficient but the as.vector functions always duplicating).
>
> -- 
> 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

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

Re: [Rd] often unnecessary duplicate in sapply / as.vector

[Thomas Lumley]

On Tue, 11 Jul 2006, Martin Morgan wrote:

> This is because RObjToCPtr is not quite careful enough with NAMED,
> rather than an issue with as.XXX

But DUP=FALSE is documented to be dangerous for this very reason. It never 
copies, and ?.C makes it clear that .C(,DUP=FALSE) can modify variables 
that it should not have any access to by normal rules.  The example of 
safe use modifies only a newly created, anonymous numeric vector.

-thomas

>
> tmp.c: void tmp(double *x) { x[0]=1; return; }
>
>> f <- function(x) x
>> x <- 0
>> .C("tmp", f(x), DUP=FALSE)
> [[1]]
> [1] 1
>
>> x
> [1] 1
>
>> x <- 0
>> y <- x
>> .C("tmp", x, DUP=FALSE)
> [[1]]
> [1] 1
>
>> y
> [1] 1
>
> Martin
>
> Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>
>> On Tue, 11 Jul 2006, Prof Brian Ripley wrote:
>>
>>> On Fri, 7 Jul 2006, Thomas Lumley wrote:
>>
 On Fri, 7 Jul 2006, Martin Morgan wrote:
>>
>> [...]
>>
> More generally, perhaps as.vector might not duplicate when mode(x) == 
> mode ?

 This isn't a trivial change, because  mode(x)==mode does not guarantee
 that as.vector(x, mode) has no effect.  For example, with mode="numeric" it
 removes attributes.
>>>
>>> And with mode="list" it does not (although that is not as documented).
>>> We can certainly do better.  [This is another of those cases where 'mode'
>>> is confusing, and in fact it would be typeof(x) == mode.]
>>
>> Aargh: of course I should have guessed that quite a few people have
>> written code that assumes that e.g. as.double() duplicates.  The first I
>> came across is a .Fortran call in smooth.spline with DUP=FALSE which
>> despite all the warnings changes its 'w' argument and hence the return
>> result from smooth.spline if as.double is made more efficient.
>>
>> I really have no desire to spend any more time tracking down problems
>> caused by such rogue code, so I am going to leave this as is (with as.list
>> somewhat more efficient but the as.vector functions always duplicating).
>>
>> --
>> 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
>
> __
> 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] Dropping unused levels of a factor that has "NA" as a level

[Peter Dalgaard]

"J. Hosking" <[EMAIL PROTECTED]> writes:

> Is this a bug?
> 
>> f1 <- factor(c("a", NA), levels = c("a", "NA") )
>> f2 <- f1[, drop = TRUE]
>> f2
>[1] a
>Levels: a 
> 
> I would have expected f2 to have only one level, "a".  It seems
> to me that the code in [.factor does not follow the advice in
> help("factor") on how to set factor codes to be missing when
> "NA" is a level of the factor.


Something odd is going on, that's for sure...

The problem is also there with factor(f1). And the logic in
as.character.factor seems to be at the root of it:

> as.character.factor
function (x, ...)
{
cx <- levels(x)[x]
if ("NA" %in% levels(x))
cx[is.na(x)] <- ""
cx
}
 
This looks like something from before we had character NA values. I
wonder if it is a mistake or there could actually be a reason to
keep it. 

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

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

[Rd] Linux/MacOSX and "X11 protocol error: BadWindow..." warnings

[David Firth]

This concerns behaviour which has been noted previously, for 
example see 

 http://tolstoy.newcastle.edu.au/R/help/05/03/0844.html
 http://tolstoy.newcastle.edu.au/R/help/03b/6873.html

and especially the thread

 http://tolstoy.newcastle.edu.au/R/help/04/08/3025.html

I find that it affects both my Linux and Mac OS X setups.  
It is a feature which has caused some (at least John Fox in 
the Rcmdr package) to make special moves to catch the 
warnings and hide them from users.

In an effort to pin it down, outside of Rcmdr or any 
packages other than tcltk itself, I came up with a simple 
reproducible example.  Essentially, the sequence that gives 
the warnings is
  tktoplevel()
[then close the Tk window using the window controls]
  X11()
  tktoplevel()
[then close the Tk window using the wondow controls]

Closing the second Tk window is the act that seems to 
provoke the warnings (see the two session transcripts 
below).  The number of warnings is different on my two 
systems, but I don't know whather that's to do with OS, or 
X11, or the two different versions of R, or what.

Without the call to X11(), I do not get the warnings.  And 
the call to X11() seemingly needs to come *after* the first 
tktoplevel() call in order for the warnings to be 
generated.

Unfortunately I do not have access to other systems on which 
to test this, or the necessary knowledge of X11, Tk etc to 
be able to debug it.  I am noting it here only in the hope 
that it might be useful to someone else on R-devel who is 
better placed to identify the likely cause(s).

best wishes,
David
-- 
Professor David Firth
http://www.warwick.ac.uk/go/dfirth


* On Linux (SUSE 10.0) with R 2.3.1 
* and xorg-x11 version 6.8.2-100
[EMAIL PROTECTED]:~> R --vanilla

R : Copyright 2006, The R Foundation for Statistical 
Computing
Version 2.3.1 (2006-06-01)
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> options(warn = 1)
> library(tcltk)
Loading Tcl/Tk interface ... done
> tktoplevel()
$ID
[1] ".1"

$env


attr(,"class")
[1] "tkwin"
##  Now close the Tk window using window controls
> X11()
> tktoplevel()
$ID
[1] ".2"

$env


attr(,"class")
[1] "tkwin"
##  Now close the Tk window using window controls
> Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)
Warning: X11 protocol error: BadWindow (invalid Window 
parameter)

> version
   _
platform   i686-pc-linux-gnu
arch   i686
os linux-gnu
system i686, linux-gnu
status
major  2
minor  3.1
year   2006
month  06
day01
svn rev38247
language   R
version.string Version 2.3.1 (2006-06-01)



* On Mac OS 10.4, using R 2.2.0 
david% R --vanilla

R : Copyright 2005, The R Foundation for Statistical 
Computing
Version 2.2.0  (2005-10-06 r35749)
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for a HTML browser interface to help.
Type 'q()' to quit R.

> options(warn=1)
> library(tcltk)
Loading Tcl/Tk interface ... done
> tktoplevel()
$ID
[1] ".1"

$env


attr(,"class")
[1] "tkwin"
##  Now close the Tk window using window controls
> X11()
> tktoplevel()
$ID
[1] ".2"

$env


attr(,"class")
[1] "tkwin"
##  Now clos

Re: [Rd] Dropping unused levels of a factor that has "NA" as a level

[Brahm, David]

I mentioned this in R-help on April 28:


| as.character.factor contains this line (where cx=levels(x)[x]):
|   if ("NA" %in% levels(x)) cx[is.na(x)] <- ""
|
| Is it possible that this is no longer the desired behavior?  These
| two results don't seem very consistent:
|
| > as.character(as.factor(c("AB", "CD", NA)))
| [1] "AB" "CD" NA  
| > is.na(.Last.value)[3]
| [1] TRUE
|
| > as.character(as.factor(c("NA", "CD", NA)))
| [1] "NA"   "CD"   ""
| > is.na(.Last.value)[3]
| [1] FALSE
|
| I'm using R-2.3.0 on Redhat Linux, but I don't think the behavior
| is new (maybe since character NA's were introduced?).
|
| -- David Brahm ([EMAIL PROTECTED])


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Dalgaard
Sent: Tuesday, July 11, 2006 5:59 PM
To: J. Hosking
Cc: r-devel@stat.math.ethz.ch
Subject: Re: [Rd] Dropping unused levels of a factor that has "NA" as a level

"J. Hosking" <[EMAIL PROTECTED]> writes:

> Is this a bug?
> 
>> f1 <- factor(c("a", NA), levels = c("a", "NA") )
>> f2 <- f1[, drop = TRUE]
>> f2
>[1] a
>Levels: a 
> 
> I would have expected f2 to have only one level, "a".  It seems
> to me that the code in [.factor does not follow the advice in
> help("factor") on how to set factor codes to be missing when
> "NA" is a level of the factor.


Something odd is going on, that's for sure...

The problem is also there with factor(f1). And the logic in
as.character.factor seems to be at the root of it:

> as.character.factor
function (x, ...)
{
cx <- levels(x)[x]
if ("NA" %in% levels(x))
cx[is.na(x)] <- ""
cx
}
 
This looks like something from before we had character NA values. I
wonder if it is a mistake or there could actually be a reason to
keep it. 

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
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] Linux/MacOSX and "X11 protocol error: BadWindow..." warnings

[Peter Dalgaard]

David Firth <[EMAIL PROTECTED]> writes:

> In an effort to pin it down, outside of Rcmdr or any 
> packages other than tcltk itself, I came up with a simple 
> reproducible example.  Essentially, the sequence that gives 
> the warnings is
>   tktoplevel()
> [then close the Tk window using the window controls]
>   X11()
>   tktoplevel()
> [then close the Tk window using the wondow controls]
> 
> Closing the second Tk window is the act that seems to 
> provoke the warnings (see the two session transcripts 
> below).  The number of warnings is different on my two 
> systems, but I don't know whather that's to do with OS, or 
> X11, or the two different versions of R, or what.
> 
> Without the call to X11(), I do not get the warnings.  And 
> the call to X11() seemingly needs to come *after* the first 
> tktoplevel() call in order for the warnings to be 
> generated.
> 
> Unfortunately I do not have access to other systems on which 
> to test this, or the necessary knowledge of X11, Tk etc to 
> be able to debug it.  I am noting it here only in the hope 
> that it might be useful to someone else on R-devel who is 
> better placed to identify the likely cause(s).

I can reproduce this with on Fedora Core 5.

One might guess is that this has to do with the intertwining of the
two event loops. Not unlikely, the X11 event handler is discarding
some events that the Tcl/Tk event handler should have known about.
I've meddled with both, but it was many moons ago...


-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

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

[Rd] read.spss() cannot import some SPSS files (PR#9074)

[tim . bock]

Full_Name: Tim Bock
Version: 2.3.1
OS: Windows XP
Submission from: (NULL) (220.233.111.181)


SPSS v12 on Windows sometimes writes files with a layout_code of 3 instead of
the usual layout_code of 2.  While I don't know what this signifies, R is able
to read these files if I change sfm-read.c to accept 3.

Also, R issues an unnecessary warning when it finds records of type 7 with
sub-type 7.  These records describe multiple-response sets, which can safely be
ignored.

Here are my suggested changes, based on the foreign_0.8-15.tar.gz.  (I'd be
happy to commit these via svn, but I assume that this is not allowed for
non-core developers.)

413a414
>   case 7: /* Multiple-response sets (later versions of 
SPSS). */
580a582
>   R_int32 orig_layout_code;
651c653
<   if (hdr.layout_code == 2)
---
>   if (hdr.layout_code == 2 || hdr.layout_code == 3)
654a657
>   orig_layout_code = hdr.layout_code;
656,658c659,661
<   if (hdr.layout_code != 2)
<   lose ((_("%s: File layout code has unexpected value %d.  Value 
should be 2, in big-endian or little-endian format"),
<  h->fn, hdr.layout_code));
---
>   if (hdr.layout_code != 2 && hdr.layout_code != 3)
>   lose ((_("%s: File layout code has unexpected value %d (or %d, 
endian-reversed).  Value should be 2 or 3, in big-endian or little-endian
format"),
>  h->fn, orig_layout_code, hdr.layout_code));

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