Nabble - R devel

Re: Sending signals to current R process from R running under MS Windows (c.f. Esc)

2009-11-28T05:45:04Z

Hi,

here is some discussion/information in the same vein:

(1) R-help thread '[R] The R "fork"', March 18, 2006:

https://stat.ethz.ch/pipermail/r-help/2006-March/101913.html

(2) R-devel thread '[Rd] New simpleExit() condition (Was: Re: Can
example() code stop the example without generating an error?)', March
14-16, 2006:

https://stat.ethz.ch/pipermail/r-devel/2006-March/036861.html

(3) Regarding sending SIGINT on Windows, I posted the following
question (without replies): 'Fix Unix' thread 'Sending/generating
SIGINT to process', Oct 1, 2007:

http://fixunix.com/microsoft-windows/30232-sending-generating-sigint-process.html

/Henrik

On Sat, Nov 28, 2009 at 10:54 AM, Graham Williams
<Graham.Williams@...> wrote:

> I am using RGtk2 for a simple GUI (rattle).
>
> I start rattle from the RGui and I remain able to interact with the
> RGui while rattle runs.
>
> Under MS/Windows, when rattle has initiated some other underlying R
> command the rattle GUI remains responsive (unlike under GNU/Linux
> where it is not responsive until the underlying command completes).
>
> I can interrupt the running command with a press of the Esc key in the RGui.
>
> I want to have a button on the rattle GUI to run an R command to have
> the same behavior as pressing the Esc key in the RGui. I currently
> have a button in rattle as an example that will run another R command
> whilst the original R command is still running.
>
> Looking at the C source code for the RGui it looks like it is sending
> a SIGBREAK signal to the R process.
>
> Is this possible to do, somehow, from R?
>
> Thanks,
> Graham
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

Sending signals to current R process from R running under MS Windows (c.f. Esc)

2009-11-28T01:54:03Z

I am using RGtk2 for a simple GUI (rattle).

I start rattle from the RGui and I remain able to interact with the
RGui while rattle runs.

Under MS/Windows, when rattle has initiated some other underlying R
command the rattle GUI remains responsive (unlike under GNU/Linux
where it is not responsive until the underlying command completes).

I can interrupt the running command with a press of the Esc key in the RGui.

I want to have a button on the rattle GUI to run an R command to have
the same behavior as pressing the Esc key in the RGui. I currently
have a button in rattle as an example that will run another R command
whilst the original R command is still running.

Looking at the C source code for the RGui it looks like it is sending
a SIGBREAK signal to the R process.

Is this possible to do, somehow, from R?

Thanks,
Graham

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

[Fwd: opened symbols in libR.so available.]

2009-11-28T01:50:57Z

Hi.

I've patched Dirk Eddelbuettel's Debian package of R, namely r-base, in
order to make hidden symbols of the library libR.so available is now
available:

http://yziquel.homelinux.org/debian/pool/main/r/r-base/

For instance, the mkPROMISE symbol is available:

> yziquel@seldon:/usr/lib/R/lib$ nm -D libR.so | grep mkPROMISE
> 000000000011f6f0 T Rf_mkPROMISE
> yziquel@seldon:/usr/lib/R/lib$

Instructions for my personal repository are available here:

http://yziquel.homelinux.org/topos/debian-repository.html

I hope this will be useful to people who wish to develop
things, test things, reverse-engineer things from the libR.so library.

I've been told that there's an interesting scheme, used by r-base-ra, to
make packages coexist with R. As of now, it simply replaces the Debian
version number, currently -1, with the Debian version number -1hackable.

All the best,

--
Guillaume Yziquel
http://yziquel.homelinux.org/

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

Re: p-generalized normal distribution

2009-11-27T17:55:11Z

Steve Kalke <steve.kalke <at> uni-rostock.de> writes:

> I would like to know if there is an R-package available for
> computing the density, distribution function,
> quantiles and random
> numbers of the p-generalized normal distribution or
> if somebody is already working on it.

I haven't been able to find out what the p-generalized normal
distribution is: the only paper I can find is

Sinz, F., and M. Bethge$. 2009. Characterization of the p-generalized
normal distribution. Journal of Multivariate Analysis 100:817-820.
doi: 10.1016/j.jmva.2008.07.006.

and I don't have access to it at the moment (although it does
at least hint that the required distribution is multivariate;
maybe p-dimensional?).

Is it the same as this?

Goodman, I. R., and S. Kotz. 1973. Multivariate θ-generalized normal
distributions. Journal of Multivariate Analysis 3:204-219. doi:
10.1016/0047-259X(73)90023-7.

Where can we find a description?

(Short answer: as far as I can tell, it doesn't exist in
R, but it would be good to have more information ...)

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

Re: Long execution time for quantile() and difftime objects (PR#14092)

2009-11-27T06:15:12Z

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--27501778-1317196171-1259330723=:5696
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.LFD.2.00.0911271406411.5696@...>

Did you read the help page?

x: numeric vector whose sample quantiles are wanted. ¡NA¢ and
¡NaN¢ values are not allowed unless ¡na.rm¢ is ¡TRUE¢.

so only 'numeric' vectors are really supported, although it does say

The default method does not allow factors, but works with objects
sufficiently like numeric vectors that ¡sort¢, addition and
multiplication work correctly. In principle only sorts and
weighted means are needed, so datatimes could have quantiles - but
this is not implemented.

There is no claim that it works (let alone works well) for class
"difftime". If you follow the link to 'sort' it says

The default ¡sort¢ method makes use of ¡order¢ for objects with
classes, which in turn makes use of the generic function ¡xtfrm¢.

and from ?xtfrm

The default method will make use of ¡==¢ and ¡>¢ methods for the
class of ¡x[i]¢ (for integers ¡i¢), and the ¡is.na¢ method for the
class of ¡x¢, but might be rather slow when doing so.

So, if you want this to be fast, you need to write an xtfrm method.
There is one in R-devel

> xtfrm.difftime
function (x)
as.numeric(x)

and you can use that in your workspace (and your example is fast in
R-devel, because of that function I think, there being other
development work in progress in the version I tried).

On Fri, 27 Nov 2009, hong.ooi@... wrote:

> Full_Name: Hong Ooi
> Version: 2.10.0
> OS: Windows XP
> Submission from: (NULL) (203.110.235.1)
>
>
> While trying to get summary statistics on a duration variable (the difference
> between a start and end date), I ran into the following issue. Using summary or
> quantile (which summary calls) on a difftime object takes an extremely long time
> if the object is even moderately large.
>
> A reproducible example:
>
>> x <- as.Date(1:10000, origin="1900-01-01")
>> x[1:10]
> [1] "1900-01-02" "1900-01-03" "1900-01-04" "1900-01-05" "1900-01-06"
> [6] "1900-01-07" "1900-01-08" "1900-01-09" "1900-01-10" "1900-01-11"
>> d <- x - as.Date("1900-01-01")
>> d[1:10]
> Time differences in days
> [1] 1 2 3 4 5 6 7 8 9 10
>> system.time(summary(d[1:10]))
> user system elapsed
> 0.01 0.00 0.01
>> system.time(summary(d[1:100]))
> user system elapsed
> 0.21 0.00 0.20
>> system.time(summary(d[1:1000]))
> user system elapsed
> 3.02 0.00 3.02
>> system.time(summary(d[1:10000]))
> user system elapsed
> 43.56 0.04 43.66
>
>
> If I unclass d, there is no problem:
>
>> system.time(summary(unclass(d[1:10000])))
> user system elapsed
> 0 0 0
>
> Testing with Rprof() indicates that the problem lies in [.difftime, although the
> code for that function seems innocuous enough.
>
>
>> sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
> [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
> [5] LC_TIME=English_Australia.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

--
Brian D. Ripley, ripley@...
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, UK Fax: +44 1865 272595
--27501778-1317196171-1259330723=:5696--

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

Re: Long execution time for quantile() and difftime objects (PR#14091)

2009-11-27T06:09:55Z

Did you read the help page?

x: numeric vector whose sample quantiles are wanted. ‘NA’ and
‘NaN’ values are not allowed unless ‘na.rm’ is ‘TRUE’.

so only 'numeric' vectors are really supported, although it does say

The default method does not allow factors, but works with objects
sufficiently like numeric vectors that ‘sort’, addition and
multiplication work correctly. In principle only sorts and
weighted means are needed, so datatimes could have quantiles - but
this is not implemented.

There is no claim that it works (let alone works well) for class
"difftime". If you follow the link to 'sort' it says

The default ‘sort’ method makes use of ‘order’ for objects with
classes, which in turn makes use of the generic function ‘xtfrm’.

and from ?xtfrm

The default method will make use of ‘==’ and ‘>’ methods for the
class of ‘x[i]’ (for integers ‘i’), and the ‘is.na’ method for the
class of ‘x’, but might be rather slow when doing so.

So, if you want this to be fast, you need to write an xtfrm method.
There is one in R-devel

> xtfrm.difftime
function (x)
as.numeric(x)

and you can use that in your workspace (and your example is fast in
R-devel, because of that function I think, there being other
development work in progress in the version I tried).

On Fri, 27 Nov 2009, hong.ooi@... wrote:

--
Brian D. Ripley, ripley@...
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, UK Fax: +44 1865 272595
______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Long execution time for quantile() and difftime objects (PR#14091)

2009-11-26T21:55:10Z

Full_Name: Hong Ooi
Version: 2.10.0
OS: Windows XP
Submission from: (NULL) (203.110.235.1)

While trying to get summary statistics on a duration variable (the difference
between a start and end date), I ran into the following issue. Using summary or
quantile (which summary calls) on a difftime object takes an extremely long time
if the object is even moderately large.

A reproducible example:

> x <- as.Date(1:10000, origin="1900-01-01")
> x[1:10]
[1] "1900-01-02" "1900-01-03" "1900-01-04" "1900-01-05" "1900-01-06"
[6] "1900-01-07" "1900-01-08" "1900-01-09" "1900-01-10" "1900-01-11"
> d <- x - as.Date("1900-01-01")
> d[1:10]
Time differences in days
[1] 1 2 3 4 5 6 7 8 9 10
> system.time(summary(d[1:10]))
user system elapsed
0.01 0.00 0.01
> system.time(summary(d[1:100]))
user system elapsed
0.21 0.00 0.20
> system.time(summary(d[1:1000]))
user system elapsed
3.02 0.00 3.02
> system.time(summary(d[1:10000]))
user system elapsed
43.56 0.04 43.66

If I unclass d, there is no problem:

> system.time(summary(unclass(d[1:10000])))
user system elapsed
0 0 0

Testing with Rprof() indicates that the problem lies in [.difftime, although the
code for that function seems innocuous enough.

> sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32

locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252

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

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

Re: compiling on snow leopard: Cocoa errors?!?!?!

2009-11-26T21:37:28Z

Simon,

Thanks for your help. I uninstalled and reinstalled xcode and gfortran. I got it direct from the website this time :p All was happy on the configure and make install.

Cheers,

Paul

On 27 Nov 2009, at 03:14, Simon Urbanek wrote:

> Paul,
>
> On Nov 26, 2009, at 9:03 PM, Homer Paul Benton wrote:
>
>> I'm currently using
>>
>> gcc --version
>> i686-apple-darwin8-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5564)
>
> That is the wrong compiler - it's a Leopard compiler (Xcode 3.1/3.1.1 to be precise - see that it says darwin8 which is even 10.4 = Tiger!). Your Xcode seems to be seriously messed up -- I'd strongly recommend re-installing all Xcode 3.2 (run sudo gfortran-uninstall before you start) and Fortran (either the CRAN version or the Snow Leopard(!!) version from Tools).
>
>
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> sh-3.2# gfortran --version
>> GNU Fortran (GCC) 4.2.1 (Apple Inc. build 5564)
>> Copyright (C) 2007 Free Software Foundation, Inc.
>>
>> GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
>> You may redistribute copies of GNU Fortran
>> under the terms of the GNU General Public License.
>> For more information about these matters, see the file named COPYING
>>
>>
>> and xcode 3.2 (1610)
>>
>> At the risk of sounding stupid, I compiled the netCDF library and the compiliers seemed happy for that. ?!?!
>>
>
> NetCDF doesn't use anything from the system so even wrong compilers won't throw it off.
>
> Cheers,
> Simon
>
>
>> Cheers,
>>
>> Paul
>>
>> I downloaded and 'installed' the
>>
>> On 27 Nov 2009, at 00:54, Simon Urbanek wrote:
>>
>>> Paul,
>>>
>>> at a first glance that seems like an issue in your system to me since
>>> the errors come from system headers and not from our code. Which
>>> compilers are you using and which Xcode version?
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>> On Nov 26, 2009, at 1:16 PM, Homer Paul Benton wrote:
>>>
>>>> Dear R-gurus,
>>>>
>>>> I'm trying to compile R on my new mac. It's snow leopard. So far
>>>> I've seemed to be doing pretty well. I've looked at
>>>>
>>>> http://cran.r-project.org/bin/macosx/tools/
>>>>
>>>> http://r.research.att.com/exp/
>>>>
>>>> http://r.research.att.com/building.html
>>>>
>>>> http://r.research.att.com/tools/
>>>>
>>>> All of which have been very helpful. Looking at the threads I've got
>>>> around some X11 issues that stopped the configure script working but
>>>> now when I excute make I get the error below. Any ideas?
>>>>
>>>> Thanks in advance,
>>>>
>>>> Paul
>>>>
>>>> R is now configured for i386-apple-darwin10.2.0
>>>>
>>>> Source directory: .
>>>> Installation directory: /Library/Frameworks
>>>>
>>>> C compiler: gcc -arch x86_64 -std=gnu99 -g -O2
>>>> Fortran 77 compiler: gfortran -arch x86_64 -g -O2
>>>>
>>>> C++ compiler: g++ -arch x86_64 -g -O2
>>>> Fortran 90/95 compiler: gfortran -arch x86_64 -g -O2
>>>> Obj-C compiler: gcc -arch x86_64 -g -O2
>>>>
>>>> Interfaces supported: X11, aqua, tcltk
>>>> External libraries: readline, BLAS(vecLib), LAPACK(in blas),
>>>> ICU
>>>> Additional capabilities: NLS
>>>> Options enabled: framework, R profiling, Java
>>>>
>>>> Recommended packages: yes
>>>>
>>>> sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc -
>>>> arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch
>>>> x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" --
>>>> with-system-zlib --with-blas='-framework vecLib' --with-lapack --x-
>>>> includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib'
>>>> X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt
>>>>
>>>>
>>>> sh-3.2# make
>>>> make[1]: Nothing to be done for `R'.
>>>> make[1]: Nothing to be done for `R'.
>>>> make[2]: Nothing to be done for `R'.
>>>> .....
>>>> ..... etc
>>>> building package 'tools'
>>>> all.R is unchanged
>>>> make[6]: `Makedeps' is up to date.
>>>> ../../../../library/tools/libs/x86_64/tools.so is unchanged
>>>> building package 'utils'
>>>> all.R is unchanged
>>>> make[4]: Nothing to be done for `iconvlist'.
>>>> building package 'grDevices'
>>>> all.R is unchanged
>>>> ../../../library/grDevices/R/grDevices is unchanged
>>>> gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 -
>>>> I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/
>>>> local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o
>>>> In file included from /System/Library/Frameworks/
>>>> Foundation.framework/Headers/NSCharacterSet.h:8,
>>>> from /System/Library/Frameworks/Foundation.framework/
>>>> Headers/Foundation.h:15,
>>>> from /System/Library/Frameworks/Cocoa.framework/
>>>> Headers/Cocoa.h:12,
>>>> from qdCocoa.h:39,
>>>> from qdCocoa.m:24:
>>>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
>>>> 278: error: format string argument follows the args to be formatted
>>>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
>>>> 280: error: format string argument follows the args to be formatted
>>>> In file included from /System/Library/Frameworks/
>>>> Foundation.framework/Headers/Foundation.h:25,
>>>> from /System/Library/Frameworks/Cocoa.framework/
>>>> Headers/Cocoa.h:12,
>>>> from qdCocoa.h:39,
>>>> from qdCocoa.m:24:
>>>> /System/Library/Frameworks/Foundation.framework/Headers/
>>>> NSException.h:62: error: format string argument follows the args to
>>>> be formatted
>>>> qdCocoa.m: In function '+[QuartzCocoaView
>>>> quartzWindowWithRect:andInfo:]':
>>>> qdCocoa.m:90: warning: class 'QuartzCocoaView' does not implement
>>>> the 'NSWindowDelegate' protocol
>>>> make[5]: *** [qdCocoa.o] Error 1
>>>> make[4]: *** [mksrc] Error 1
>>>> make[3]: *** [all] Error 2
>>>> make[2]: *** [R] Error 1
>>>> make[1]: *** [R] Error 1
>>>> make: *** [R] Error 1
>>>> ______________________________________________
>>>> R-devel@... mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>>
>>>
>>
>>
>>
>

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

Re: compiling on snow leopard: Cocoa errors?!?!?!

2009-11-26T19:14:26Z

Paul,

On Nov 26, 2009, at 9:03 PM, Homer Paul Benton wrote:

> I'm currently using
>
> gcc --version
> i686-apple-darwin8-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5564)

That is the wrong compiler - it's a Leopard compiler (Xcode 3.1/3.1.1 to be precise - see that it says darwin8 which is even 10.4 = Tiger!). Your Xcode seems to be seriously messed up -- I'd strongly recommend re-installing all Xcode 3.2 (run sudo gfortran-uninstall before you start) and Fortran (either the CRAN version or the Snow Leopard(!!) version from Tools).

> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> sh-3.2# gfortran --version
> GNU Fortran (GCC) 4.2.1 (Apple Inc. build 5564)
> Copyright (C) 2007 Free Software Foundation, Inc.
>
> GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
> You may redistribute copies of GNU Fortran
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING
>
>
> and xcode 3.2 (1610)
>
> At the risk of sounding stupid, I compiled the netCDF library and the compiliers seemed happy for that. ?!?!
>

NetCDF doesn't use anything from the system so even wrong compilers won't throw it off.

Cheers,
Simon

> Cheers,
>
> Paul
>
> I downloaded and 'installed' the
>
> On 27 Nov 2009, at 00:54, Simon Urbanek wrote:
>
>> Paul,
>>
>> at a first glance that seems like an issue in your system to me since
>> the errors come from system headers and not from our code. Which
>> compilers are you using and which Xcode version?
>>
>> Cheers,
>> Simon
>>
>>
>> On Nov 26, 2009, at 1:16 PM, Homer Paul Benton wrote:
>>
>>> Dear R-gurus,
>>>
>>> I'm trying to compile R on my new mac. It's snow leopard. So far
>>> I've seemed to be doing pretty well. I've looked at
>>>
>>> http://cran.r-project.org/bin/macosx/tools/
>>>
>>> http://r.research.att.com/exp/
>>>
>>> http://r.research.att.com/building.html
>>>
>>> http://r.research.att.com/tools/
>>>
>>> All of which have been very helpful. Looking at the threads I've got
>>> around some X11 issues that stopped the configure script working but
>>> now when I excute make I get the error below. Any ideas?
>>>
>>> Thanks in advance,
>>>
>>> Paul
>>>
>>> R is now configured for i386-apple-darwin10.2.0
>>>
>>> Source directory: .
>>> Installation directory: /Library/Frameworks
>>>
>>> C compiler: gcc -arch x86_64 -std=gnu99 -g -O2
>>> Fortran 77 compiler: gfortran -arch x86_64 -g -O2
>>>
>>> C++ compiler: g++ -arch x86_64 -g -O2
>>> Fortran 90/95 compiler: gfortran -arch x86_64 -g -O2
>>> Obj-C compiler: gcc -arch x86_64 -g -O2
>>>
>>> Interfaces supported: X11, aqua, tcltk
>>> External libraries: readline, BLAS(vecLib), LAPACK(in blas),
>>> ICU
>>> Additional capabilities: NLS
>>> Options enabled: framework, R profiling, Java
>>>
>>> Recommended packages: yes
>>>
>>> sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc -
>>> arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch
>>> x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" --
>>> with-system-zlib --with-blas='-framework vecLib' --with-lapack --x-
>>> includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib'
>>> X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt
>>>
>>>
>>> sh-3.2# make
>>> make[1]: Nothing to be done for `R'.
>>> make[1]: Nothing to be done for `R'.
>>> make[2]: Nothing to be done for `R'.
>>> .....
>>> ..... etc
>>> building package 'tools'
>>> all.R is unchanged
>>> make[6]: `Makedeps' is up to date.
>>> ../../../../library/tools/libs/x86_64/tools.so is unchanged
>>> building package 'utils'
>>> all.R is unchanged
>>> make[4]: Nothing to be done for `iconvlist'.
>>> building package 'grDevices'
>>> all.R is unchanged
>>> ../../../library/grDevices/R/grDevices is unchanged
>>> gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 -
>>> I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/
>>> local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o
>>> In file included from /System/Library/Frameworks/
>>> Foundation.framework/Headers/NSCharacterSet.h:8,
>>> from /System/Library/Frameworks/Foundation.framework/
>>> Headers/Foundation.h:15,
>>> from /System/Library/Frameworks/Cocoa.framework/
>>> Headers/Cocoa.h:12,
>>> from qdCocoa.h:39,
>>> from qdCocoa.m:24:
>>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
>>> 278: error: format string argument follows the args to be formatted
>>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
>>> 280: error: format string argument follows the args to be formatted
>>> In file included from /System/Library/Frameworks/
>>> Foundation.framework/Headers/Foundation.h:25,
>>> from /System/Library/Frameworks/Cocoa.framework/
>>> Headers/Cocoa.h:12,
>>> from qdCocoa.h:39,
>>> from qdCocoa.m:24:
>>> /System/Library/Frameworks/Foundation.framework/Headers/
>>> NSException.h:62: error: format string argument follows the args to
>>> be formatted
>>> qdCocoa.m: In function '+[QuartzCocoaView
>>> quartzWindowWithRect:andInfo:]':
>>> qdCocoa.m:90: warning: class 'QuartzCocoaView' does not implement
>>> the 'NSWindowDelegate' protocol
>>> make[5]: *** [qdCocoa.o] Error 1
>>> make[4]: *** [mksrc] Error 1
>>> make[3]: *** [all] Error 2
>>> make[2]: *** [R] Error 1
>>> make[1]: *** [R] Error 1
>>> make: *** [R] Error 1
>>> ______________________________________________
>>> R-devel@... mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>
>
>

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

Re: compiling on snow leopard: Cocoa errors?!?!?!

2009-11-26T18:03:47Z

Simon,

I'm currently using

gcc --version
i686-apple-darwin8-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5564)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

sh-3.2# gfortran --version
GNU Fortran (GCC) 4.2.1 (Apple Inc. build 5564)
Copyright (C) 2007 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

and xcode 3.2 (1610)

At the risk of sounding stupid, I compiled the netCDF library and the compiliers seemed happy for that. ?!?!

Cheers,

Paul

I downloaded and 'installed' the

On 27 Nov 2009, at 00:54, Simon Urbanek wrote:

> Paul,
>
> at a first glance that seems like an issue in your system to me since
> the errors come from system headers and not from our code. Which
> compilers are you using and which Xcode version?
>
> Cheers,
> Simon
>
>
> On Nov 26, 2009, at 1:16 PM, Homer Paul Benton wrote:
>
>> Dear R-gurus,
>>
>> I'm trying to compile R on my new mac. It's snow leopard. So far
>> I've seemed to be doing pretty well. I've looked at
>>
>> http://cran.r-project.org/bin/macosx/tools/
>>
>> http://r.research.att.com/exp/
>>
>> http://r.research.att.com/building.html
>>
>> http://r.research.att.com/tools/
>>
>> All of which have been very helpful. Looking at the threads I've got
>> around some X11 issues that stopped the configure script working but
>> now when I excute make I get the error below. Any ideas?
>>
>> Thanks in advance,
>>
>> Paul
>>
>> R is now configured for i386-apple-darwin10.2.0
>>
>> Source directory: .
>> Installation directory: /Library/Frameworks
>>
>> C compiler: gcc -arch x86_64 -std=gnu99 -g -O2
>> Fortran 77 compiler: gfortran -arch x86_64 -g -O2
>>
>> C++ compiler: g++ -arch x86_64 -g -O2
>> Fortran 90/95 compiler: gfortran -arch x86_64 -g -O2
>> Obj-C compiler: gcc -arch x86_64 -g -O2
>>
>> Interfaces supported: X11, aqua, tcltk
>> External libraries: readline, BLAS(vecLib), LAPACK(in blas),
>> ICU
>> Additional capabilities: NLS
>> Options enabled: framework, R profiling, Java
>>
>> Recommended packages: yes
>>
>> sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc -
>> arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch
>> x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" --
>> with-system-zlib --with-blas='-framework vecLib' --with-lapack --x-
>> includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib'
>> X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt
>>
>>
>> sh-3.2# make
>> make[1]: Nothing to be done for `R'.
>> make[1]: Nothing to be done for `R'.
>> make[2]: Nothing to be done for `R'.
>> .....
>> ..... etc
>> building package 'tools'
>> all.R is unchanged
>> make[6]: `Makedeps' is up to date.
>> ../../../../library/tools/libs/x86_64/tools.so is unchanged
>> building package 'utils'
>> all.R is unchanged
>> make[4]: Nothing to be done for `iconvlist'.
>> building package 'grDevices'
>> all.R is unchanged
>> ../../../library/grDevices/R/grDevices is unchanged
>> gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 -
>> I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/
>> local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o
>> In file included from /System/Library/Frameworks/
>> Foundation.framework/Headers/NSCharacterSet.h:8,
>> from /System/Library/Frameworks/Foundation.framework/
>> Headers/Foundation.h:15,
>> from /System/Library/Frameworks/Cocoa.framework/
>> Headers/Cocoa.h:12,
>> from qdCocoa.h:39,
>> from qdCocoa.m:24:
>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
>> 278: error: format string argument follows the args to be formatted
>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
>> 280: error: format string argument follows the args to be formatted
>> In file included from /System/Library/Frameworks/
>> Foundation.framework/Headers/Foundation.h:25,
>> from /System/Library/Frameworks/Cocoa.framework/
>> Headers/Cocoa.h:12,
>> from qdCocoa.h:39,
>> from qdCocoa.m:24:
>> /System/Library/Frameworks/Foundation.framework/Headers/
>> NSException.h:62: error: format string argument follows the args to
>> be formatted
>> qdCocoa.m: In function '+[QuartzCocoaView
>> quartzWindowWithRect:andInfo:]':
>> qdCocoa.m:90: warning: class 'QuartzCocoaView' does not implement
>> the 'NSWindowDelegate' protocol
>> make[5]: *** [qdCocoa.o] Error 1
>> make[4]: *** [mksrc] Error 1
>> make[3]: *** [all] Error 2
>> make[2]: *** [R] Error 1
>> make[1]: *** [R] Error 1
>> make: *** [R] Error 1
>> ______________________________________________
>> R-devel@... mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>

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

Re: compiling on snow leopard: Cocoa errors?!?!?!

2009-11-26T16:54:28Z

Paul,

at a first glance that seems like an issue in your system to me since
the errors come from system headers and not from our code. Which
compilers are you using and which Xcode version?

Cheers,
Simon

On Nov 26, 2009, at 1:16 PM, Homer Paul Benton wrote:

> Dear R-gurus,
>
> I'm trying to compile R on my new mac. It's snow leopard. So far
> I've seemed to be doing pretty well. I've looked at
>
> http://cran.r-project.org/bin/macosx/tools/
>
> http://r.research.att.com/exp/
>
> http://r.research.att.com/building.html
>
> http://r.research.att.com/tools/
>
> All of which have been very helpful. Looking at the threads I've got
> around some X11 issues that stopped the configure script working but
> now when I excute make I get the error below. Any ideas?
>
> Thanks in advance,
>
> Paul
>
> R is now configured for i386-apple-darwin10.2.0
>
> Source directory: .
> Installation directory: /Library/Frameworks
>
> C compiler: gcc -arch x86_64 -std=gnu99 -g -O2
> Fortran 77 compiler: gfortran -arch x86_64 -g -O2
>
> C++ compiler: g++ -arch x86_64 -g -O2
> Fortran 90/95 compiler: gfortran -arch x86_64 -g -O2
> Obj-C compiler: gcc -arch x86_64 -g -O2
>
> Interfaces supported: X11, aqua, tcltk
> External libraries: readline, BLAS(vecLib), LAPACK(in blas),
> ICU
> Additional capabilities: NLS
> Options enabled: framework, R profiling, Java
>
> Recommended packages: yes
>
> sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc -
> arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch
> x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" --
> with-system-zlib --with-blas='-framework vecLib' --with-lapack --x-
> includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib'
> X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt
>
>
> sh-3.2# make
> make[1]: Nothing to be done for `R'.
> make[1]: Nothing to be done for `R'.
> make[2]: Nothing to be done for `R'.
> .....
> ..... etc
> building package 'tools'
> all.R is unchanged
> make[6]: `Makedeps' is up to date.
> ../../../../library/tools/libs/x86_64/tools.so is unchanged
> building package 'utils'
> all.R is unchanged
> make[4]: Nothing to be done for `iconvlist'.
> building package 'grDevices'
> all.R is unchanged
> ../../../library/grDevices/R/grDevices is unchanged
> gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 -
> I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/
> local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o
> In file included from /System/Library/Frameworks/
> Foundation.framework/Headers/NSCharacterSet.h:8,
> from /System/Library/Frameworks/Foundation.framework/
> Headers/Foundation.h:15,
> from /System/Library/Frameworks/Cocoa.framework/
> Headers/Cocoa.h:12,
> from qdCocoa.h:39,
> from qdCocoa.m:24:
> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
> 278: error: format string argument follows the args to be formatted
> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:
> 280: error: format string argument follows the args to be formatted
> In file included from /System/Library/Frameworks/
> Foundation.framework/Headers/Foundation.h:25,
> from /System/Library/Frameworks/Cocoa.framework/
> Headers/Cocoa.h:12,
> from qdCocoa.h:39,
> from qdCocoa.m:24:
> /System/Library/Frameworks/Foundation.framework/Headers/
> NSException.h:62: error: format string argument follows the args to
> be formatted
> qdCocoa.m: In function '+[QuartzCocoaView
> quartzWindowWithRect:andInfo:]':
> qdCocoa.m:90: warning: class 'QuartzCocoaView' does not implement
> the 'NSWindowDelegate' protocol
> make[5]: *** [qdCocoa.o] Error 1
> make[4]: *** [mksrc] Error 1
> make[3]: *** [all] Error 2
> make[2]: *** [R] Error 1
> make[1]: *** [R] Error 1
> make: *** [R] Error 1
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

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

Re: p-generalized normal distribution

2009-11-26T13:01:26Z

He already asked... And I don t know any pkg implementing this
distribution...

iPhone.fan

Le 26 nov. 2009 à 21:22, Kjetil Halvorsen <kjetilbrinchmannhalvorsen@...
m> a écrit :

> There is a CRAN Task View for probability Distributions. take a look
> there!
>
> Kjetil
>
> On Tue, Nov 24, 2009 at 1:53 PM, Steve Kalke <steve.kalke@...
> > wrote:
>> Hello,
>>
>> I would like to know if there is an R-package available for
>> computing the
>> density, distribution function, quantiles and random numbers of the
>> p-generalized normal distribution or if somebody is already working
>> on it.
>>
>> Best regards,
>> Steve Kalke
>>
>> ______________________________________________
>> R-devel@... mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: p-generalized normal distribution

2009-11-26T12:22:24Z

There is a CRAN Task View for probability Distributions. take a look there!

Kjetil

On Tue, Nov 24, 2009 at 1:53 PM, Steve Kalke <steve.kalke@...> wrote:

> Hello,
>
> I would like to know if there is an R-package available for computing the
> density, distribution function, quantiles and random numbers of the
> p-generalized normal distribution or if somebody is already working on it.
>
> Best regards,
> Steve Kalke
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

compiling on snow leopard: Cocoa errors?!?!?!

2009-11-26T10:16:28Z

Dear R-gurus,

I'm trying to compile R on my new mac. It's snow leopard. So far I've seemed to be doing pretty well. I've looked at

http://cran.r-project.org/bin/macosx/tools/

http://r.research.att.com/exp/

http://r.research.att.com/building.html

http://r.research.att.com/tools/

All of which have been very helpful. Looking at the threads I've got around some X11 issues that stopped the configure script working but now when I excute make I get the error below. Any ideas?

Thanks in advance,

Paul

R is now configured for i386-apple-darwin10.2.0

Source directory: .
Installation directory: /Library/Frameworks

C compiler: gcc -arch x86_64 -std=gnu99 -g -O2
Fortran 77 compiler: gfortran -arch x86_64 -g -O2

C++ compiler: g++ -arch x86_64 -g -O2
Fortran 90/95 compiler: gfortran -arch x86_64 -g -O2
Obj-C compiler: gcc -arch x86_64 -g -O2

Interfaces supported: X11, aqua, tcltk
External libraries: readline, BLAS(vecLib), LAPACK(in blas), ICU
Additional capabilities: NLS
Options enabled: framework, R profiling, Java

Recommended packages: yes

sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc -arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" --with-system-zlib --with-blas='-framework vecLib' --with-lapack --x-includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib' X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt

sh-3.2# make
make[1]: Nothing to be done for `R'.
make[1]: Nothing to be done for `R'.
make[2]: Nothing to be done for `R'.
.....
..... etc
building package 'tools'
all.R is unchanged
make[6]: `Makedeps' is up to date.
../../../../library/tools/libs/x86_64/tools.so is unchanged
building package 'utils'
all.R is unchanged
make[4]: Nothing to be done for `iconvlist'.
building package 'grDevices'
all.R is unchanged
../../../library/grDevices/R/grDevices is unchanged
gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 -I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o
In file included from /System/Library/Frameworks/Foundation.framework/Headers/NSCharacterSet.h:8,
from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:15,
from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
from qdCocoa.h:39,
from qdCocoa.m:24:
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:278: error: format string argument follows the args to be formatted
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:280: error: format string argument follows the args to be formatted
In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:25,
from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
from qdCocoa.h:39,
from qdCocoa.m:24:
/System/Library/Frameworks/Foundation.framework/Headers/NSException.h:62: error: format string argument follows the args to be formatted
qdCocoa.m: In function '+[QuartzCocoaView quartzWindowWithRect:andInfo:]':
qdCocoa.m:90: warning: class 'QuartzCocoaView' does not implement the 'NSWindowDelegate' protocol
make[5]: *** [qdCocoa.o] Error 1
make[4]: *** [mksrc] Error 1
make[3]: *** [all] Error 2
make[2]: *** [R] Error 1
make[1]: *** [R] Error 1
make: *** [R] Error 1
______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: "bug report" field in DESCRIPTION file?

2009-11-26T09:38:14Z

On Thu, Nov 26, 2009 at 1:39 PM, Duncan Murdoch <murdoch@...> wrote:

> This sounds like a good idea, though I would add a "package" parameter to
> the bug.report() function, rather than creating a new function.

I'm sure when I did help.search("bug") and help.search("report") this
morning I didn't see this function! Otherwise I would have suggested
that. bug.report(package="bazbrain"). Oh dear, no maintainer.

> Does the logic below sound right for bug.report() with the package
> specified?
>
> If there's a BugReports field, bug.report() calls browseURL() on that page.
>
> If not, it does more or less what it does now, but
> - it defaults "address" to the package maintainer. - it adds a line in the
> intro to the message pointing to the URL field if there was one.

Martin Maechler's reservation about not being able to fill in the R
details for bug reports on trackers isn't too much of a problem, since
the bug tracker form could have fields for R version, session info
etc, or at least a big warning saying "Please include the following
info" (inside a <blink> tag).

So how about if bug.report(package="foo") has a BugReports: field,
you print out 'The following information may be useful to your bug
report' and dump the relevant things ready for cut n paste into a bug
tracker, then browseURL().

Barry

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

Re: "bug report" field in DESCRIPTION file?

2009-11-26T07:00:03Z

On 26/11/2009 9:20 AM, Martin Maechler wrote:

> >>>>> "DM" == Duncan Murdoch <murdoch@...>
> >>>>> on Thu, 26 Nov 2009 08:39:27 -0500 writes:
>
> DM> On 26/11/2009 7:09 AM, Barry Rowlingson wrote:
> >> A lot of R packages are now effectively maintained by several people
> >> and so use sites like R-forge or google code for development. This
> >> means the best way to report bugs or problems with these packages is
> >> via the development site's bug tracking rather than emailing the
> >> maintainer. Could we agree on a field in DESCRIPTION explicitly for
> >> bug reports?
> >>
> >> The DESCRIPTION file has an optional URL field which generally sends
> >> the user to the 'home page' of the package. Whether or not there is a
> >> bug tracker somewhere there isn't made explicit, so I don't think
> >> overloading URL for a bug report address is a good idea. The Hmisc
> >> package mentions its bug tracker in the Description field and also has
> >> it in the URL field with three other URLs. This tells me a bug report
> >> field might be a better idea.
> >>
> >> I'd prefer an optional field called 'BugReports:', which would be a
> >> URL, and this could either be the http: address of a web site bug
> >> tracker or a mailto: URL (of a real live human or a mail-based
> >> tracker).
> >>
> >> If there's agreement on this then a further step may be to write a
> >> 'bugreport(package)' function that would first look for a BugReport
> >> field, then the URL or maintainer fields to give the poor confused
> >> user some advice on what to do. Then when someone emails R-dev saying
> >> they think there's a bug in package foo, we can say "Have you read the
> >> output of 'bugreport("foo")'?" which might be more helpful than saying
> >> 'bugs with 'foo' should be reported to the maintainer'.
> >>
>
> DM> This sounds like a good idea, though I would add a "package" parameter
> DM> to the bug.report() function, rather than creating a new function.
>
> I agree (good idea; use bug.report() with arguments).
>
> DM> Does the logic below sound right for bug.report() with the package
> DM> specified?
>
> DM> If there's a BugReports field, bug.report() calls browseURL() on that page.
>
> I'm not sure if that's easy: One main reason for bug.report() is
> to auto-collect the necessary info and put it into the body of
> an e-mail message. So, I think the above only "works" when the
> BugReports fields is a 'mailto:' URL, but not, e.g., when it
> points to an R-forge bug tracking web page form.
>

The idea was that we would not use the auto-collection at all if there
was a BugReports field, because the package author(s) had indicated by
it that they didn't want emailed bug reports.

Duncan Murdoch

> DM> If not, it does more or less what it does now, but
> DM> - it defaults "address" to the package maintainer.
> DM> - it adds a line in the intro to the message pointing to the URL field
> DM> if there was one.
>
> that sounds good.
> Martin
>
>
> DM> Duncan Murdoch
>
>
> >> Just an idea for a rainy morning...
> >>
> >> Barry
> >>
> >> ______________________________________________
> >> R-devel@... mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
>
> DM> ______________________________________________
> DM> R-devel@... mailing list
> DM> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

Re: "bug report" field in DESCRIPTION file?

2009-11-26T06:20:37Z

>>>>> "DM" == Duncan Murdoch <murdoch@...>
>>>>> on Thu, 26 Nov 2009 08:39:27 -0500 writes:

DM> On 26/11/2009 7:09 AM, Barry Rowlingson wrote:
>> A lot of R packages are now effectively maintained by several people
>> and so use sites like R-forge or google code for development. This
>> means the best way to report bugs or problems with these packages is
>> via the development site's bug tracking rather than emailing the
>> maintainer. Could we agree on a field in DESCRIPTION explicitly for
>> bug reports?
>>
>> The DESCRIPTION file has an optional URL field which generally sends
>> the user to the 'home page' of the package. Whether or not there is a
>> bug tracker somewhere there isn't made explicit, so I don't think
>> overloading URL for a bug report address is a good idea. The Hmisc
>> package mentions its bug tracker in the Description field and also has
>> it in the URL field with three other URLs. This tells me a bug report
>> field might be a better idea.
>>
>> I'd prefer an optional field called 'BugReports:', which would be a
>> URL, and this could either be the http: address of a web site bug
>> tracker or a mailto: URL (of a real live human or a mail-based
>> tracker).
>>
>> If there's agreement on this then a further step may be to write a
>> 'bugreport(package)' function that would first look for a BugReport
>> field, then the URL or maintainer fields to give the poor confused
>> user some advice on what to do. Then when someone emails R-dev saying
>> they think there's a bug in package foo, we can say "Have you read the
>> output of 'bugreport("foo")'?" which might be more helpful than saying
>> 'bugs with 'foo' should be reported to the maintainer'.
>>

DM> This sounds like a good idea, though I would add a "package" parameter
DM> to the bug.report() function, rather than creating a new function.

I agree (good idea; use bug.report() with arguments).

DM> Does the logic below sound right for bug.report() with the package
DM> specified?

DM> If there's a BugReports field, bug.report() calls browseURL() on that page.

I'm not sure if that's easy: One main reason for bug.report() is
to auto-collect the necessary info and put it into the body of
an e-mail message. So, I think the above only "works" when the
BugReports fields is a 'mailto:' URL, but not, e.g., when it
points to an R-forge bug tracking web page form.

DM> If not, it does more or less what it does now, but
DM> - it defaults "address" to the package maintainer.
DM> - it adds a line in the intro to the message pointing to the URL field
DM> if there was one.

that sounds good.
Martin

DM> Duncan Murdoch

>> Just an idea for a rainy morning...
>>
>> Barry
>>
>> ______________________________________________
>> R-devel@... mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

DM> ______________________________________________
DM> R-devel@... mailing list
DM> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: "bug report" field in DESCRIPTION file?

2009-11-26T05:39:27Z

On 26/11/2009 7:09 AM, Barry Rowlingson wrote:

> A lot of R packages are now effectively maintained by several people
> and so use sites like R-forge or google code for development. This
> means the best way to report bugs or problems with these packages is
> via the development site's bug tracking rather than emailing the
> maintainer. Could we agree on a field in DESCRIPTION explicitly for
> bug reports?
>
> The DESCRIPTION file has an optional URL field which generally sends
> the user to the 'home page' of the package. Whether or not there is a
> bug tracker somewhere there isn't made explicit, so I don't think
> overloading URL for a bug report address is a good idea. The Hmisc
> package mentions its bug tracker in the Description field and also has
> it in the URL field with three other URLs. This tells me a bug report
> field might be a better idea.
>
> I'd prefer an optional field called 'BugReports:', which would be a
> URL, and this could either be the http: address of a web site bug
> tracker or a mailto: URL (of a real live human or a mail-based
> tracker).
>
> If there's agreement on this then a further step may be to write a
> 'bugreport(package)' function that would first look for a BugReport
> field, then the URL or maintainer fields to give the poor confused
> user some advice on what to do. Then when someone emails R-dev saying
> they think there's a bug in package foo, we can say "Have you read the
> output of 'bugreport("foo")'?" which might be more helpful than saying
> 'bugs with 'foo' should be reported to the maintainer'.
>

This sounds like a good idea, though I would add a "package" parameter
to the bug.report() function, rather than creating a new function.

Does the logic below sound right for bug.report() with the package
specified?

If there's a BugReports field, bug.report() calls browseURL() on that page.

If not, it does more or less what it does now, but
- it defaults "address" to the package maintainer.
- it adds a line in the intro to the message pointing to the URL field
if there was one.

Duncan Murdoch

> Just an idea for a rainy morning...
>
> Barry
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

"bug report" field in DESCRIPTION file?

2009-11-26T04:09:49Z

A lot of R packages are now effectively maintained by several people
and so use sites like R-forge or google code for development. This
means the best way to report bugs or problems with these packages is
via the development site's bug tracking rather than emailing the
maintainer. Could we agree on a field in DESCRIPTION explicitly for
bug reports?

The DESCRIPTION file has an optional URL field which generally sends
the user to the 'home page' of the package. Whether or not there is a
bug tracker somewhere there isn't made explicit, so I don't think
overloading URL for a bug report address is a good idea. The Hmisc
package mentions its bug tracker in the Description field and also has
it in the URL field with three other URLs. This tells me a bug report
field might be a better idea.

I'd prefer an optional field called 'BugReports:', which would be a
URL, and this could either be the http: address of a web site bug
tracker or a mailto: URL (of a real live human or a mail-based
tracker).

If there's agreement on this then a further step may be to write a
'bugreport(package)' function that would first look for a BugReport
field, then the URL or maintainer fields to give the poor confused
user some advice on what to do. Then when someone emails R-dev saying
they think there's a bug in package foo, we can say "Have you read the
output of 'bugreport("foo")'?" which might be more helpful than saying
'bugs with 'foo' should be reported to the maintainer'.

Just an idea for a rainy morning...

Barry

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

Detaching one package can remove the S4 methods of another (PR#14087)

2009-11-26T00:15:09Z

Putting on public record

library(spdep)
showMethods("[")
detach("package:spdep", unload = TRUE)
detach("package:Matrix", unload=TRUE)
showMethods("[") # sp methods still there
detach("package:spam", unload = TRUE)
showMethods("[") # sp methods have gone

This is one of several examples found by package testing in R-devel
(this one from BayesX) with _R_CHECK_UNLOAD_NAMESPACES_ set.

Session info after the first command:
R version 2.10.0 Patched (2009-11-23 r50545)
x86_64-unknown-linux-gnu

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

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

other attached packages:
[1] spdep_0.4-52 nlme_3.1-96 coda_0.13-4 MASS_7.3-4
[5] Matrix_0.999375-32 lattice_0.17-26 spam_0.15-5 boot_1.2-41
[9] maptools_0.7-26 foreign_0.8-38 sp_0.9-47 deldir_0.0-10

loaded via a namespace (and not attached):
[1] grid_2.10.0

Happens also in 2.10.0 and
R version 2.11.0 Under development (unstable) (2009-11-25 r50568)

--
Brian D. Ripley, ripley@...
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, UK Fax: +44 1865 272595

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

Re: Question about image() behavior

2009-11-25T12:57:19Z

On 25/11/2009 3:00 PM, Justin McGrath wrote:

> If the x vector has a gap, then image() fills in those spots using the z
> value of the nearest x value. I had expected it to just leave those spaces
> blank though.
>
> For example
> x=c(1:5,100:105)
> y=c(1:10)
> z=matrix(rnorm(100),10,10)
> image(x,y,z)
>
> I expected that to produce a figure with a wide vertical gap between x=5 and
> x=100.
>
> Is this the correct behavior? Could there be an option added to choose
> between these two behaviors? Either way, it should be stated in the
> documentation.

It's doing what is documented. Giving uneven spacing to x values just
says that the rectangles being coloured by the z values are not square.

If you want to leave blanks, then put in NA values for z.

For example,

x <- c(1:6, 100:105)
y <- 1:10
z <- matrix(rnorm(110), 11, 10)
z[6,] <- NA
image(x,y,z)

Duncan Murdoch

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

Question about image() behavior

2009-11-25T12:00:00Z

If the x vector has a gap, then image() fills in those spots using the z
value of the nearest x value. I had expected it to just leave those spaces
blank though.

For example
x=c(1:5,100:105)
y=c(1:10)
z=matrix(rnorm(100),10,10)
image(x,y,z)

I expected that to produce a figure with a wide vertical gap between x=5 and
x=100.

Is this the correct behavior? Could there be an option added to choose
between these two behaviors? Either way, it should be stated in the
documentation.

Justin

[[alternative HTML version deleted]]

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

heatmap.2 gives wrong colorkey with unequally spaced breaks (PR#14085)

2009-11-25T08:15:10Z

Full_Name: Joris FA Meys
Version: 2.10.0
OS: Windows XP
Submission from: (NULL) (157.193.194.73)

I use the enhanced heatmap function in gplots : heatmap.2

For the presentation of the color key, the code is not 100% adequate. More
specifically, in case you define unequally spaced breaks :

1) the keyplot ignores the minimum and maximum of these breaks.

Code changed in line 323 and 324 to :
min.raw <- min(c(x,breaks), na.rm = TRUE)
max.raw <- max(c(x,breaks), na.rm = TRUE)

2) the keyplot gives the histogram with the correct breaks, but the colors
remain equally spaced. This is due to the lack of a specification for x in the
call to the image() function.

Code changed in line 327-328 to :
image(x=breaks,z = matrix(z, ncol = 1), col = col, breaks = tmpbreaks,
xaxt = "n", yaxt = "n")

Line numbers obtained by copy-pasting code from console into Tinn-R. The changed
code is how I adapted the function in order to get the desired result. Don't
know if it's error-proof, but it works for me.

Cheers
Joris

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

Re: Bug in all.equal() or in the plm package

2009-11-25T07:21:19Z

Hi,

sorry for replying so late to this. I somehow missed the original thread
and was just pointed to it by Yves...

>>> I noticed that there is a (minor) bug either the command all.equal()
>>> or in the "plm" package. I demonstrate this using an example taken
>>> from the documentation of plm():
>>>
>>
>> I'm not sure this is a bug, but I'd call it at least a design flaw.
>> The problem is that the length.Formula method in the Formula package
>> (which plm depends on) returns a vector of length 2. Now there's
>> nothing in R that requires length() to return a scalar, but all.equal
>> assumes it does, and I'd guess there are lots of other places this
>> assumption is made.

Well, ?length says:

The default method currently returns an 'integer' of length 1.
Since this may change in the future and may differ for other
methods, programmers should not rely on it.

The problem IMO is that the all.equal() method for "formula" gets called
by inheritance without assuring that it works. I think we just need to
supply a suitable all.equal() method for "Formula" objects.

>> Okay, let's call it "design flaw". Given that the "unusual" behaviour
>> of length.Formula() causes this problem, I suggest that the
>> length.Formula() method should be changed. Maybe to something like

> R> a <- as.Formula( y ~ x | z | w )
> # current behaviour:
> R> length(a)
> [1] 1 3
> # suggested behaviour:
> R> length(a)
> [1] 2

This wouldn't be correct either because this is not a list of length 2. A
"Formula" is a "formula" (of length 2 or 3) with two attributes ("lhs" and
"rhs"). Thus, currently length() does not reflect the internal structure
but rather the conceptual structure (of a formula consiting of a LHS and
RHS, both with a certain length).

Unless there are good reasons to do otherwise, I would keep the length()
method and just supply a suitable all.equal() method for
"Formula" objects.

hth,
Z

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

Possible bug in "unsplit" (PR#14084)

2009-11-25T06:30:12Z

Dear R-bug-people

I have encountered a problem with "unsplit", which I believe may be
caused by a bug in the function. However, unexpericend with bug-reports
I apologise if this is barely a user problem rather than a problem
within R.

The problem occurs if an object is split by several grouping factors
with levels not occuring in the data, and using drop = TRUE. This may
appear as a special and hardly relevant case, but I had to split a data
frame on several factors, do some analyses on each of the subsets in the
splitted object, and then unsplit it. I had to use drop = TRUE,
otherwise my analyses would not run. Nevertheless, I found a fix to the
unsplit, which I suggest is due to that the drop-argument not is
maintained in the call to unsplit within unsplit. Description and
example below. The problem was found on R version 2.9.0 and 2.10.0 on
windows XP.

> sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32

locale:
[1] LC_COLLATE=Norwegian (Bokmål)_Norway.1252 LC_CTYPE=Norwegian
(Bokmål)_Norway.1252
[3] LC_MONETARY=Norwegian (Bokmål)_Norway.1252 LC_NUMERIC=C
[5] LC_TIME=Norwegian (Bokmål)_Norway.1252

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

loaded via a namespace (and not attached):
[1] tools_2.10.0
>
## a reproducable example:
dff <- data.frame(gr1=factor(c(1,1,1,1,1,2,2,2,2,2,2),
levels=c(1,2,3,4)), gr2=factor(c(1,2,1,2,1,2,1,2,1,2,3),
levels=c(1,2,3,4)), yy=rnorm(11))
# note that the two groups "gr1" and "gr2" have defined levels which not
occur in the data.

dff2 <- split(dff, list(dff$gr1, dff$gr2), drop=TRUE)
# I dont want empty objects, so I use drop=TRUE

# now I want to unsplit it, and expect the following to work:
dff3 <- unsplit(dff2, list(dff$gr1, dff$gr2), drop=TRUE)
Error in `row.names<-.data.frame`(`*tmp*`, value = c("1", "11", "3",
"11", :
duplicate 'row.names' are not allowed
In addition: Warning message:
non-unique values when setting 'row.names': 1, 11, 3, 5

### end

Looking at the unsplit function, we find:
> unsplit
function (value, f, drop = FALSE)
{
len <- length(if (is.list(f)) f[[1L]] else f)
if (is.data.frame(value[[1L]])) {
x <- value[[1L]][rep(NA, len), , drop = FALSE]
rownames(x) <- unsplit(lapply(value, rownames), f)
}
else x <- value[[1L]][rep(NA, len)]
split(x, f, drop = drop) <- value
x
}
<environment: namespace:base>
>

Note that if "value" is a data.frame, then rownames for the output x is
made by the call:
rownames(x) <- unsplit(lapply(value, rownames), f)

This call to unsplit ignores the drop-argument, and in the example above
we get from this call:
> unsplit(lapply(dff2, rownames), list(dff$gr1, dff$gr2))
[1] "1" "11" "3" "11" "5" "1" "7" "3" "9" "5" "11"

i.e. not unique row names for the output x.

A simple fix is to add drop = drop to that argument, such that the
updated unsplit (here called unsplit2) is like this:

unsplit2 <- function (value, f, drop = FALSE)
{
len <- length(if (is.list(f)) f[[1L]] else f)
if (is.data.frame(value[[1L]])) {
x <- value[[1L]][rep(NA, len), , drop = FALSE]
rownames(x) <- unsplit(lapply(value, rownames), f, drop=drop) # note new
"drop=drop"
}
else x <- value[[1L]][rep(NA, len)]
split(x, f, drop = drop) <- value
x
}

This works fine in the example above, and the original levels in gr1 and
gr2 (i.e. they both have four levels) are maintained in the output data
frame such that it has similar attributes as the orignial dff:

> dff3 <- unsplit2(dff2, list(dff$gr1, dff$gr2), drop=TRUE)
> dff3
gr1 gr2 yy
1 1 1 2.13749771
2 1 2 -0.02166458
3 1 1 0.45960452
4 1 2 2.72074958
5 1 1 -0.17536995
6 2 2 -0.08909495
7 2 1 0.94260802
8 2 2 -0.09979505
9 2 1 1.22240834
10 2 2 -0.81710781
11 2 3 0.76071130
>

I must admit that I have not the possiblity to check if such a quick-fix
conflicts with other use of unsplit or on other types of data, but I
cannot see that it should be a problem.

Sincerely

Ivar Herfindal
--------------------------------
Centre for Conservation Biology
Norwegian University for Science and Technology
N-7491 Trondheim, Norway

email: ivar.herfindal@...

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

Re: group generics

2009-11-25T06:21:32Z

Hi Ross --

Ross Boylan <ross@...> writes:

> I have classes A and B, where B contains A. In the implementation of
> the group generic for B I would like to use the corresponding group
> generic for A. Is there a way to do that?
>
> I would also appreciate any comments if what I'm trying to do seems like
> the wrong approach.
>
> Here's a stripped down example:
> setClass("A",
> representation=representation(xa="numeric")
> )
>
> setMethod("Arith", signature(e1="numeric", e2="A"), function(e1, e2) {
> new("A", ax=e1*e2@xa)

typo, I guess, xa = e1...

> }
> )
>
> setClass("B",
> representation=representation(xb="numeric"),
> contains=c("A")
> )
>
> setMethod("Arith", signature(e1="numeric", e2="B"), function(e1, e2) {
> # the next line does not work right
> v <- selectMethod("callGeneric", signature=c("numeric", "A"))(e1, e2)

v <- callGeneric(e1, as(e2, "A"))

or probably

v <- callNextMethod(e1, e2)

Martin

> print(v)
> new("B", v, xb=e1*e2@xb)
> }
> )
>
>
> Results:
>> t1 <- new("B", new("A", xa=4), xb=2)
>> t1
> An object of class “B”
> Slot "xb":
> [1] 2
>
> Slot "xa":
> [1] 4
>
>> 3*t1
> Error in getGeneric(f, !optional) :
> no generic function found for "callGeneric"
>
> Thanks.
> Ross Boylan
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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

Re: Error in parse(outFile)

2009-11-25T04:01:02Z

Pamela McCaskie wrote:

> Hi all
>
> I have made some changes to a package (SimHap) I wrote a couple of years
> ago, and it has passed R CMD check under windows, but under linux
> (ubuntu jaunty) I am getting the following error:
>
>
>
> * installing *source* package 'SimHap' ...
>
> ** R
>
> Error in parse(outFile) : 2:1: unexpected $end
>
> ERROR: unable to collate files for package 'SimHap'
>
>
>
> Does anyone know what the "outFile" it is referring to here, and why
> this would be happening in a linux build, but not in windows. In both
> cases I'm using R 2.10.0.
>

When installing a package, R collects all the source into one big file
and parses it all at once. The filename is stored internally in a
variable called "outFile".

I don't know what would be causing this difference between Windows and
Linux. If you can send me a copy of the package offline I'll take a
look later today.

Duncan Murdoch

>
>
> Cheers
>
> Pam
>
>
>
> Dr Pamela McCaskie
>
> Assistant Professor
>
> Centre for Genetic Epidemiology and Biostatistics
>
> M409
>
> University of Western Australia
>
>
>
> Email: pam.mccaskie@...
>
> Ph: 6488 6741
>
> Fax: 6488 6750
>
>
>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

Re: Method dispatch for function

2009-11-25T01:42:02Z

>>>>> "SM" == Stavros Macrakis <macrakis@...>
>>>>> on Mon, 23 Nov 2009 11:24:24 -0500 writes:

SM> (I had sent this to r-help and got no responses -- perhaps r-devel is
SM> a better list for this question?)

Definitely better, yes.

SM> How can I determine what S3 method will be called for a particular
SM> first-argument class?

SM> I was imagining something like functionDispatch('str','numeric') =>
SM> utils:::str.default , but I can't find anything like this.

SM> For that matter, I was wondering if anyone had written a version of
SM> `methods` which gave their fully qualified names if they were not
SM> visible, e.g.

SM> methods('str') =>
SM>     utils:::str.data.frame    utils:::str.default
SM> stats:::str.dendrogram    stats:::str.logLik    utils:::str.POSIXt

SM> or

SM> methods('str') =>
SM>      $utils
SM>            "str.data.frame" "str.default"    "str.POSIXt"
SM>      $stats
SM>            "str.dendrogram" "str.logLik"

I'm pretty sure that basically, the current methods() function
"contains" the necessary information internally already
(but beware: methods() is not the simplest of our functions !)

I'd be welcoming back-compatible patches to methods() {*and*
the corresponding *.Rd file !} which would provide such
functionality.

I think I would introduce a third optional argument
(logical or character, specifying the "variants"),
and the result could easily become back-compatible if the extra information
you want is put as a new column in the "info" attribute (a data
frame) of the current methods() result.

SM> Thank you,

You are welcome,
Martin Maechler, ETH Zurich

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

Re: The "lib" argument in install.packages().

2009-11-24T23:41:32Z

Rolf,

If you want to avoid the warning, why not use lib=.libPaths()[1]?
This is not to say that your suggestions aren't useful.

Cheers,
Peter Ehlers

Rolf Turner wrote:

>
> I was flummoxed for a long time by errors generated when I did
> something like
>
> install.packages(foo,lib="Rlib")
>
> where ``Rlib'' is my personalized directory of R packages, which
> lives in my home directory (from which I started R before issuing
> the foregoing install.packages() call.
>
> Recently someone (I forget who, but thanks very much to whomever
> it was) pointed out that I needed to specify the complete pathname,
> i.e. "/Users/rturner/Rlib" rather than the relative pathname "Rlib"
> or "./Rlib" (which I'd also tried). When the complete pathname is
> given the install.packages() call works seamlessly.
>
> Remark: I have "/Users/rturner/Rlib" as the first entry of my .libPaths(),
> so just doing install.packages(foo) works --- but this gives a warning
> about lib not being specified, which I find irksome.
>
> Questions:
>
> (1) Why is it that the complete pathname of ``lib'' has to
> be specified? Cannot the code of install.packages() be
> adjusted to work with relative pathnames?
>
> (2) If indeed this is not possible, wouldn't it be kind and
> helpful, to us young ( :-) ) and naive persons, to put an
> indication in the help file for install.packages that the
> complete pathname is required?
>
> cheers,
>
> Rolf Turner
>
> P. S. > sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-apple-darwin8.11.1
>
> locale:
> [1] C
>
> attached base packages:
> [1] datasets utils stats graphics grDevices methods base
>
> other attached packages:
> [1] misc_0.0-11 fortunes_1.3-6 MASS_7.3-3
>
>
> ######################################################################
> Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

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

Re: Question R's parser : - parsing "x=\n 1"

2009-11-24T22:09:51Z

On Nov 25, 2009, at 1:03 AM, Saptarshi Guha wrote:

> Hello
> I was reading the source main/src/gram.y and had one question, how
> does R parse
>
> x =
> 1
>
> According the grammar:
>
> prog : END_OF_INPUT { return 0; }
> | '\n' { return xxvalue(NULL,2,NULL); }
> | expr_or_assign '\n' { return xxvalue($1,3,&@1); }
> | expr_or_assign ';' { return xxvalue($1,4,&@1); }
> | error { YYABORT; }
> ;
>
>
> So this should be of the 3rd form.
> Also, the expr_or_assign is of the 2nd form in
>
> expr_or_assign : expr { $$ = $1; }
> | equal_assign { $$ = $1; }
> ;
>
> where equal_assign is
>
> equal_assign : expr EQ_ASSIGN expr_or_assign { $$ =
> xxbinary($2,$1,$3); }
>
> When the parser sees 'x' and '=' it expects an expr_or_assign and we
> know it will receive an expr. However, the expr cannot be a new
> line(according to the defn of expr)
>
> So instead of an expr, the parse gets a newline and should fail.
> Q: So how does R parse this?
> I think it fails with a Parse_Incomplete and keeps on reading till EOF
> (or till an expression is complete).
> But this is not really an incomplete expression

It is. "x=" is incomplete -- try it in R and you'll see that you get a
continuation prompt because it's incomplete:

> x=
+ 1

Cheers,
S

> but if my
> interpretation is correct a syntax error, yet R parses it.
> So i understood something else or R's engine manages to do things
> differently
> Regards
> Saptarshi
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

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

Question R's parser : - parsing "x=\n 1"

2009-11-24T22:03:17Z

Hello
I was reading the source main/src/gram.y and had one question, how does R parse

x =
1

According the grammar:

prog : END_OF_INPUT { return 0; }
| '\n' { return xxvalue(NULL,2,NULL); }
| expr_or_assign '\n' { return xxvalue($1,3,&@1); }
| expr_or_assign ';' { return xxvalue($1,4,&@1); }
| error { YYABORT; }
;

So this should be of the 3rd form.
Also, the expr_or_assign is of the 2nd form in

expr_or_assign : expr { $$ = $1; }
| equal_assign { $$ = $1; }
;

where equal_assign is

equal_assign : expr EQ_ASSIGN expr_or_assign { $$ =
xxbinary($2,$1,$3); }

When the parser sees 'x' and '=' it expects an expr_or_assign and we
know it will receive an expr. However, the expr cannot be a new
line(according to the defn of expr)

So instead of an expr, the parse gets a newline and should fail.
Q: So how does R parse this?
I think it fails with a Parse_Incomplete and keeps on reading till EOF
(or till an expression is complete).
But this is not really an incomplete expression but if my
interpretation is correct a syntax error, yet R parses it.
So i understood something else or R's engine manages to do things differently
Regards
Saptarshi

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

Error in parse(outFile)

2009-11-24T20:55:03Z

Hi all

I have made some changes to a package (SimHap) I wrote a couple of years
ago, and it has passed R CMD check under windows, but under linux
(ubuntu jaunty) I am getting the following error:

* installing *source* package 'SimHap' ...

** R

Error in parse(outFile) : 2:1: unexpected $end

ERROR: unable to collate files for package 'SimHap'

Does anyone know what the "outFile" it is referring to here, and why
this would be happening in a linux build, but not in windows. In both
cases I'm using R 2.10.0.

Cheers

Pam

Dr Pamela McCaskie

Assistant Professor

Centre for Genetic Epidemiology and Biostatistics

M409

University of Western Australia

Email: pam.mccaskie@...

Ph: 6488 6741

Fax: 6488 6750

[[alternative HTML version deleted]]

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

Re: Broken installer (PR#14083)

2009-11-24T17:31:49Z

On Nov 24, 2009, at 5:45 PM, robert.a.weller@... wrote:

> Full_Name: Robert A. Weller
> Version: current
> OS: Mac OS 10.6
> Submission from: (NULL) (129.59.140.86)
>
>
> The gfortran 4.2.4 installer in the Tools section that is supposed
> to install a
> Snow Leopard (10.6) version is actually installing version 4.2.1. I
> am finding
> that the 4.2.1 compiler installed as issues e.g. in interpreting the
> -fno-automatic command line switch and also -fdefault-real-8.
>
> We looked directly into the installer and saw that it was actually
> installing
> 4.2.1. Of course, gfortran --version confirmed this.
>

You are, of course, wrong because what you're looking at is the Apple
gcc version which is the version of the driver and the cc part (it is
the gcc-42 tree of Apple). The fortran merged unto the Apple gcc
branch is indeed 4.2.4.

Cheers,
Simon

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

group generics

2009-11-24T16:34:25Z

I have classes A and B, where B contains A. In the implementation of
the group generic for B I would like to use the corresponding group
generic for A. Is there a way to do that?

I would also appreciate any comments if what I'm trying to do seems like
the wrong approach.

Here's a stripped down example:
setClass("A",
representation=representation(xa="numeric")
)

setMethod("Arith", signature(e1="numeric", e2="A"), function(e1, e2) {
new("A", ax=e1*e2@xa)
}
)

setClass("B",
representation=representation(xb="numeric"),
contains=c("A")
)

setMethod("Arith", signature(e1="numeric", e2="B"), function(e1, e2) {
# the next line does not work right
v <- selectMethod("callGeneric", signature=c("numeric", "A"))(e1, e2)
print(v)
new("B", v, xb=e1*e2@xb)
}
)

Results:
> t1 <- new("B", new("A", xa=4), xb=2)
> t1
An object of class “B”
Slot "xb":
[1] 2

Slot "xa":
[1] 4

> 3*t1
Error in getGeneric(f, !optional) :
no generic function found for "callGeneric"

Thanks.
Ross Boylan

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