[Rd] Loss of identified points

[Terry Therneau]

Minimizing and then restoring a window that contains identified points
leads to an error on my linux box.

> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=C
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=C LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=C
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=C LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

> plot(1:5, 1:5)
> identify(1:5, 1:5, letters[2:6])

# Identify a point or two, then minimize the graph window, then restore it
> Error: first argument must be a string (of length 1) or native symbol
reference

The graph returns  but the labels are lost.

Terry T.

[[alternative HTML version deleted]]

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

[Rd] cause 'invalid permissions'

[Maxpar Lin]

Hi folks,

I am writing a package in C. It works most of the time, but fails
occasionally by the segfault looking like:

address 0x7f55302e2700, cause 'invalid permissions'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

I tried gdb and it appears the application hangs at

__kernel_vsyscall ()

Since it happens randomly, I am not sure what is the exactly cause. Anyone
reached the same problem? Any point is appreciated.

Thanks.

Max

[[alternative HTML version deleted]]

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

Re: [Rd] cause 'invalid permissions'

[Prof Brian Ripley]

On 28/04/2013 17:00, Maxpar Lin wrote:

Hi folks,

I am writing a package in C. It works most of the time, but fails
occasionally by the segfault looking like:

address 0x7f55302e2700, cause 'invalid permissions'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

I tried gdb and it appears the application hangs at

__kernel_vsyscall ()

Since it happens randomly, I am not sure what is the exactly cause. Anyone
reached the same problem? Any point is appreciated.


See the debugging section in 'Writing R Extensions' (and look at the 
call stack when you use gdb).  One of the tools there such as ASan or 
valgrind will likely pinpoint your error.




Thanks.

Max

[[alternative HTML version deleted]]

__
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

Re: [Rd] Loss of identified points

[Prof Brian Ripley]

On 29/04/2013 02:54, Terry Therneau wrote:

Minimizing and then restoring a window that contains identified points
leads to an error on my linux box.


See the posting guide.  NEWS in R-patched says

• In R 3.0.0, identify() and locator() did not record information
  correctly, so replaying a graph (e.g. by copying it to another
  device) would fail. (PR#15271)

If your device does not use backing store (mine does) then minimizing 
and replaying will replay the display list.






sessionInfo()

R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8LC_COLLATE=C
  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=C LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

sessionInfo()

R version 3.0.0 (2013-04-03)
Platform: i686-pc-linux-gnu (32-bit)

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8LC_COLLATE=C
  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=C LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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


plot(1:5, 1:5)
identify(1:5, 1:5, letters[2:6])


# Identify a point or two, then minimize the graph window, then restore it

Error: first argument must be a string (of length 1) or native symbol

reference

The graph returns  but the labels are lost.

Terry T.

[[alternative HTML version deleted]]

__
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

Re: [Rd] lsfit: Error in formatting error message

[Uwe Ligges]

On 25.04.2013 13:29, Renaud Gaujoux wrote:

Hi,

in R-3.0 I get the following error when calling lsfit with more
observations than variables, which seems to come from an error in the
formatting of the error message (note that this was not happening in
2.15.3):


nobs <- 5; nvar <- 6; lsfit(matrix(runif(nobs*nvar), ncol=nvar),

runif(nobs), intercept=FALSE)
Error in sprintf(ngettext(nry, "%d response", "%d responses"), ", ",
ngettext(ncx,  :
   invalid format '%d'; use format %s for character objects

traceback()

3: sprintf(ngettext(nry, "%d response", "%d responses"), ", ",
ngettext(ncx,
"but only %d variable", "but only %d variables"), nry, ncx)
2: stop(sprintf(ngettext(nry, "%d response", "%d responses"), ", ",
ngettext(ncx, "but only %d variable", "but only %d variables"),
nry, ncx), domain = NA)
1: lsfit(matrix(runif(nobs * nvar), ncol = nvar), runif(nobs), intercept =
FALSE)


Thanks, fixed in R-patched and R-devel (plus the wording which was 
inappropriate for more than 10 years, at least).


Best,
Uwe Ligges






Thank you.

Bests,
Renaud

[[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] lsfit: Error in formatting error message

[Renaud Gaujoux]

Ah yes, nice, I had noticed the swapped words in other situations, it will
definitely help me to tell users about sample size issues... :)

Bests,
Renaud


On 29 April 2013 12:15, Uwe Ligges  wrote:

> On 25.04.2013 13:29, Renaud Gaujoux wrote:
>
>> Hi,
>>
>> in R-3.0 I get the following error when calling lsfit with more
>> observations than variables, which seems to come from an error in the
>> formatting of the error message (note that this was not happening in
>> 2.15.3):
>>
>>  nobs <- 5; nvar <- 6; lsfit(matrix(runif(nobs*nvar), ncol=nvar),
>>>
>> runif(nobs), intercept=FALSE)
>> Error in sprintf(ngettext(nry, "%d response", "%d responses"), ", ",
>> ngettext(ncx,  :
>>invalid format '%d'; use format %s for character objects
>>
>>> traceback()
>>>
>> 3: sprintf(ngettext(nry, "%d response", "%d responses"), ", ",
>> ngettext(ncx,
>> "but only %d variable", "but only %d variables"), nry, ncx)
>> 2: stop(sprintf(ngettext(nry, "%d response", "%d responses"), ", ",
>> ngettext(ncx, "but only %d variable", "but only %d variables"),
>> nry, ncx), domain = NA)
>> 1: lsfit(matrix(runif(nobs * nvar), ncol = nvar), runif(nobs), intercept =
>> FALSE)
>>
>
> Thanks, fixed in R-patched and R-devel (plus the wording which was
> inappropriate for more than 10 years, at least).
>
> Best,
> Uwe Ligges
>
>
>
>
>
>> Thank you.
>>
>> Bests,
>> Renaud
>>
>> [[alternative HTML version deleted]]
>>
>> __**
>> 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

Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

[Paul Gilbert]

Being generally uninformed about Windows, I have to admit to almost 
total confusion trying to follow this thread. However, since I have 
recently been trying to do something in Windows, I would appreciate a 
newbie friendly explanation of a few points:


-Rtools is used to build R and to build (some?) R packages. If you make 
Rtools an R package, how do you bootstrap the R build process?


-in unix-like OSes, configure is used before make to set things similar 
to the question of where to find Rtools, and what version of various 
tools are available, and give warnings and errors if these are not 
adequate. Is there a reason configure cannot be used in Windows, or is 
there not something similar?


-or am I really confused and should not consider the possibility that 
people actually build R, so the discussion is just about packages?


Thanks,
Paul

On 13-04-22 11:16 AM, Gabor Grothendieck wrote:

On Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch
 wrote:

On 21/04/2013 6:57 PM, Hadley Wickham wrote:



PS. Hadley, is this what you meant when you wrote "Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *.", or those approaches are only when you call 'R CMD'
from the R prompt?  I believe the latter, but I just want to make sure
I didn't miss something.


Well both devtools and RStudio allow you to do package development
without leaving R, so neither do anything to your path when you're not
using them.

In teaching windows users to develop R packages, I found the use of
the command line to be a substantial road-block, and if you can
develop packages without leaving R, why not?



The idea of temporary additions to the path during the INSTALL/build/check
code sounds reasonable.  R could probably do it more accurately than
devtools or RStudio can (since we know the requirements, and you have to
guess at them), but could hopefully do it in a way that isn't incompatible
with those.

The code called by install.packages() and related functions within R is
essentially the same code as called by R CMD INSTALL etc from the command
line, so this would help both cases.


I would like to comment on this as I have had to implement similar
facilities myself as part R.bat in the batchfiles.

There is an issue of keeping R and Rtools in sync.   Currently
different Rtools versions will work with the same R version.  For
example, I have used both Rtools 1927 and 1930 with the current
version of R.  Its necessary to determine the relative paths that the
version of Rtools in use requires since in principle the relative
Rtools paths can vary from one version of Rtools to the next if the
gcc version changes, say.

Ideally the system would be able to figure this out even if registry
entries and environment variables are not set by looking in standard
locations for the Rtools root and finding the relative paths by
querying some file in the Rtools installation itself.  devtools does
this by querying the Rtools version and uss an internal database of
relative paths keyed by version.   R.bat in batchfiles does it by
scanning the Rtools unins000.dat file and extracting the relative
paths directly from it.  This has the advantage that no database need
be maintained and it also automatically adapts to new versions of
Rtools without any foreknowledge of them.   Of course since you have
control of both ends you alternately could add the relative paths to
an expanded version of the VERSION file or add some additional text
file into Rtools for the purpose of identifying he relative paths..

Another possibility if significant changes were to be considered would
be to make Rtools into an R package thereby leveraging existing
facilities and much simplifying any synchronization.

--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
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] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

[Duncan Murdoch]

On 29/04/2013 7:43 AM, Paul Gilbert wrote:

Being generally uninformed about Windows, I have to admit to almost
total confusion trying to follow this thread. However, since I have
recently been trying to do something in Windows, I would appreciate a
newbie friendly explanation of a few points:

-Rtools is used to build R and to build (some?) R packages. If you make
Rtools an R package, how do you bootstrap the R build process?


Rtools used to be needed for all packages.  Nowadays packages that 
consist only of R code typically wouldn't need it.


It might be possible to make Rtools into an R package, but it would 
require quite a bit of work, because generally speaking packages don't 
provide command line executables, and we strongly prefer packages to 
contain their own source.  The Rtools source is really quite huge (since 
it contains compilers for C/C++, Fortran, and Objective C/C++, as well 
as a small collection of Unix-like tools).


-in unix-like OSes, configure is used before make to set things similar
to the question of where to find Rtools, and what version of various
tools are available, and give warnings and errors if these are not
adequate. Is there a reason configure cannot be used in Windows, or is
there not something similar?


Most bare-bones Windows systems can't run configure scripts and could 
not possibly provide the minimal tools necessary to build R, so we 
decided long ago to manually configure R for one particular toolset, 
which we maintain and distribute.


People who have Cygwin installed can use the usual Unix-style tools to 
configure R for Cygwin, but as far as I know no Cygwin maintainer has 
managed to build R so that it passes its tests.  We (in R-core) do not 
support Cygwin, putting our efforts towards the current strategy instead.





-or am I really confused and should not consider the possibility that
people actually build R, so the discussion is just about packages?


Not very many people build R on Windows, but a few do, and we support 
them by making Rtools available.


Duncan Murdoch



Thanks,
Paul

On 13-04-22 11:16 AM, Gabor Grothendieck wrote:
> On Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch
>  wrote:
>> On 21/04/2013 6:57 PM, Hadley Wickham wrote:
>>>
 PS. Hadley, is this what you meant when you wrote "Better solutions
 (e.g. Rstudio and devtools) temporarily set the path on when you're
 calling R CMD *.", or those approaches are only when you call 'R CMD'
 from the R prompt?  I believe the latter, but I just want to make sure
 I didn't miss something.
>>>
>>> Well both devtools and RStudio allow you to do package development
>>> without leaving R, so neither do anything to your path when you're not
>>> using them.
>>>
>>> In teaching windows users to develop R packages, I found the use of
>>> the command line to be a substantial road-block, and if you can
>>> develop packages without leaving R, why not?
>>
>>
>> The idea of temporary additions to the path during the INSTALL/build/check
>> code sounds reasonable.  R could probably do it more accurately than
>> devtools or RStudio can (since we know the requirements, and you have to
>> guess at them), but could hopefully do it in a way that isn't incompatible
>> with those.
>>
>> The code called by install.packages() and related functions within R is
>> essentially the same code as called by R CMD INSTALL etc from the command
>> line, so this would help both cases.
>
> I would like to comment on this as I have had to implement similar
> facilities myself as part R.bat in the batchfiles.
>
> There is an issue of keeping R and Rtools in sync.   Currently
> different Rtools versions will work with the same R version.  For
> example, I have used both Rtools 1927 and 1930 with the current
> version of R.  Its necessary to determine the relative paths that the
> version of Rtools in use requires since in principle the relative
> Rtools paths can vary from one version of Rtools to the next if the
> gcc version changes, say.
>
> Ideally the system would be able to figure this out even if registry
> entries and environment variables are not set by looking in standard
> locations for the Rtools root and finding the relative paths by
> querying some file in the Rtools installation itself.  devtools does
> this by querying the Rtools version and uss an internal database of
> relative paths keyed by version.   R.bat in batchfiles does it by
> scanning the Rtools unins000.dat file and extracting the relative
> paths directly from it.  This has the advantage that no database need
> be maintained and it also automatically adapts to new versions of
> Rtools without any foreknowledge of them.   Of course since you have
> control of both ends you alternately could add the relative paths to
> an expanded version of the VERSION file or add some additional text
> file into Rtools for the purpose of identifying he relative paths..
>
> Another possibility if significant changes were to be considered would
> 

[Rd] trace with reference class

[Kohske Takahashi]

Hi

The final line of the example in ?setRefClass induces an error:

> ## debugging all objects from class mEdit in method $undo()
> mEdit$trace(undo, browser)
Error in envRefInferField(x, what, getClass(class(x)), selfEnv) :
  'undo' is not a valid field or method name for reference class
"refGeneratorSlot"

$trace tries to embed the trace in the generator object (instead of
the generated object).
Has this functionality been removed?

best,

kohske

--
Kohske Takahashi 

Assistant Professor,
Research Center for Advanced Science and Technology,
The University of  Tokyo, Japan.
http://www.fennel.rcast.u-tokyo.ac.jp/profilee_ktakahashi.html

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