Re: [Rd] Cross-compilation
More information for you. In order to test some ideas I had I first attempted to compile the gafit package which is just a single file - this compiled fine (this is a C package). I then added the iostream library to it as so: #include and altered the extension from c to cpp so it would compile as a C++ program and I get the following: * START OUTPUT * export PATH=/my/path/RCrossBuild/cross-tools/bin:/my/path/RCrossBuild/cross-tools/mingw32/bin:/usr/local/pgsql/bin:/home/tmccallum/sbin:/usr/java/jdk1.5.0_06/bin:/usr/java/jdk1.5.0_06/jre/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tmccallum/bin; \ export mypkg=`echo gafittest | cut -d'_' -f1,1`; \ export mypkg_v=gafittest; \ cd /my/path/RCrossBuild/pkgsrc; \ rm -rf $mypkg; \ tar zxf gafittest.tar.gz; \ echo ---$mypkg--; \ cd /my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32/; \ make PKGDIR=/my/path/RCrossBuild/pkgsrc RLIB=/my/path/RCrossBuild/WinRlibs STAMP=no pkg-$mypkg; \ mkdir -p /my/path/RCrossBuild/WinRlibs; \ cd /my/path/RCrossBuild/WinRlibs; \ rm -rf $mypkg_v.zip; \ zip -rl $mypkg_v.zip $mypkg -x \*.so \*.dll \*.RData \*.rda \*.gz \*.zip \*.rds \*.pdf \*.ps;\ zip -r9 $mypkg_v.zip $mypkg -i \*.so \*.dll \*.RData \*.rda \*.gz \*.zip \*.rds \*.pdf \*.ps;\ rm -rf $mypkg_v --- gafittest-- make[1]: Entering directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' -- Making package gafittest adding build stamp to DESCRIPTION making DLL ... making gafit.d from gafit.cpp In file included from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/locale_facets.h:1533, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/basic_ios.h:44, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ios:51, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ostream:45, from /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/iostream:45, from gafit.cpp:22: /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/codecvt.h:219:45: macro "length" passed 4 arguments, but takes just 1 make[4]: *** [gafit.d] Error 1 make[3]: *** [srcDynlib] Error 2 make[2]: *** [all] Error 2 make[1]: *** [pkg-gafittest] Error 2 make[1]: Leaving directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' adding: gafittest/ (stored 0%) adding: gafittest/DESCRIPTION (deflated 41%) adding: gafittest/Meta/ (stored 0%) adding: gafittest/COPYING (deflated 62%) adding: gafittest/Meta/package.rds (deflated 54%) * END OUTPUT * I have checked the search paths and it is using the includes in gcc 3.4.5 that come with mingW32 as the docs say it should. Line 22 of gafit that it points to is where I include iostream (have tried both and "iostream" to see if it made any difference). So I think that the g++ version of mingW32 may be the problem. Any suggestions, Tom "Tom McCallum" <[EMAIL PROTECTED]> wrote: > Thanks for your reply, as an example it appears to have difficulty linking > to even ostream library of the standard C++, as shown below: > > /home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference > to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' > Classifier.o: In function `operator<<': > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:218: > > undefined reference to `_ZNSolsEd' > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:196: > > undefined reference to `_ZNSolsEl' > > I am currently working R-2.4.0 as downloaded today. > > I know the g++ has gone through some alterations and wondered if you knew > the version of g++ you cross-compiled your package with for comparison - > mine is g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). > > Many thanks > > Tom > > > On Wed, 25 Oct 2006 18:10:40 +0100, Ramon Diaz-Uriarte <[EMAIL PROTECTED]> > wrote: > > > Dear Tom, > > > > It has worked for me out-of-the box in at least two times, one a while > > ago > > with R-2.2-something and recently with R-2.4.0. In both cases, I was > > running > > Debian (with a mix of testing and unstable) on x86. I never had to do > > anything, just run the script and at least in one case I did > > crosscompile a > > package with C++. > > > > > > R. > > > > On Wednesday 25 October 2006 18:03, Tom McCallum wrote: > >> Hi everyone, > >> > >> I am trying to cross-compile a package I wrote using the Yan and Rossini > >> tutorial "Building Microsoft Windows versions of R and R packages using > >> Intel Linux". I have
Re: [Rd] Cross-compilation
False alarm, those errors were due to the old iostream R.h ordering required - so not a lead after all. Tom [EMAIL PROTECTED] wrote: > More information for you. > > In order to test some ideas I had I first attempted to compile the gafit > package which is just a single file - this compiled fine (this is a C > package). > > I then added the iostream library to it as so: > > #include > > and altered the extension from c to cpp so it would compile as a C++ program > and I get the following: > > * >START OUTPUT > * > export > PATH=/my/path/RCrossBuild/cross-tools/bin:/my/path/RCrossBuild/cross-tools/mingw32/bin:/usr/local/pgsql/bin:/home/tmccallum/sbin:/usr/java/jdk1.5.0_06/bin:/usr/java/jdk1.5.0_06/jre/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tmccallum/bin; > \ > export mypkg=`echo gafittest | cut -d'_' -f1,1`; \ > export mypkg_v=gafittest; \ > cd /my/path/RCrossBuild/pkgsrc; \ > rm -rf $mypkg; \ > tar zxf gafittest.tar.gz; \ > echo ---$mypkg--; \ > cd /my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32/; \ > make PKGDIR=/my/path/RCrossBuild/pkgsrc RLIB=/my/path/RCrossBuild/WinRlibs > STAMP=no pkg-$mypkg; \ > mkdir -p /my/path/RCrossBuild/WinRlibs; \ > cd /my/path/RCrossBuild/WinRlibs; \ > rm -rf $mypkg_v.zip; \ > zip -rl $mypkg_v.zip $mypkg -x \*.so \*.dll \*.RData \*.rda \*.gz \*.zip > \*.rds \*.pdf \*.ps;\ > zip -r9 $mypkg_v.zip $mypkg -i \*.so \*.dll \*.RData \*.rda \*.gz \*.zip > \*.rds \*.pdf \*.ps;\ > rm -rf $mypkg_v > --- gafittest-- > make[1]: Entering directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' > > -- Making package gafittest > adding build stamp to DESCRIPTION > making DLL ... > making gafit.d from gafit.cpp > In file included from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/locale_facets.h:1533, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/basic_ios.h:44, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ios:51, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/ostream:45, > from > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/iostream:45, > from gafit.cpp:22: > /my/path/RCrossBuild/cross-tools/bin/../lib/gcc/i586-mingw32/3.4.5/../../../../include/c++/3.4.5/bits/codecvt.h:219:45: > macro "length" passed 4 arguments, but takes just 1 > make[4]: *** [gafit.d] Error 1 > make[3]: *** [srcDynlib] Error 2 > make[2]: *** [all] Error 2 > make[1]: *** [pkg-gafittest] Error 2 > make[1]: Leaving directory `/my/path/RCrossBuild/WinR/R-2.4.0/src/gnuwin32' > adding: gafittest/ (stored 0%) > adding: gafittest/DESCRIPTION (deflated 41%) > adding: gafittest/Meta/ (stored 0%) > adding: gafittest/COPYING (deflated 62%) > adding: gafittest/Meta/package.rds (deflated 54%) > > * >END OUTPUT > * > > I have checked the search paths and it is using the includes in gcc 3.4.5 that > come with mingW32 as the docs say it should. Line 22 of gafit that it points > to is where I include iostream (have tried both and "iostream" to > see if it made any difference). So I think that the g++ version of mingW32 > may be the problem. > > Any suggestions, > > Tom > > > > > > "Tom McCallum" <[EMAIL PROTECTED]> wrote: > > > Thanks for your reply, as an example it appears to have difficulty linking > > to even ostream library of the standard C++, as shown below: > > > > /home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference > > to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' > > Classifier.o: In function `operator<<': > > > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:218: > > > > undefined reference to `_ZNSolsEd' > > > /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:196: > > > > undefined reference to `_ZNSolsEl' > > > > I am currently working R-2.4.0 as downloaded today. > > > > I know the g++ has gone through some alterations and wondered if you knew > > the version of g++ you cross-compiled your package with for comparison - > > mine is g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). > > > > Many thanks > > > > Tom > > > > > > On Wed, 25 Oct 2006 18:10:40 +0100, Ramon Diaz-Uriarte <[EMAIL PROTECTED]> > > wrote: > > > > > Dear Tom, > > > > > > It has worked for me out-of-the box in at least two times, one a while > > > ago > > > with R-2.2-something and recently with R-2.4.0. In both cases, I was > > > running > > > Debian (with a mix of testing and unstable) on x86. I never had to do > > > anyt
Re: [Rd] how to determine if a function's result is invisible
On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 10/25/2006 11:02 PM, Gabor Grothendieck wrote:
> > On 10/25/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> >> On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
> >>> Suppose we have a function such as the following
> >>>
> >>> F <- function(f, x) f(x)+1
> >>>
> >>> which runs function f and then transforms it. I would like the
> >>> corresponding function which works the same except that
> >>> unlike F returns an invisible result if and only if f does.
> >>>
> >>> Is there some way of determining whether f returns
> >>> an invisible result or not?
> >>>
> >>> Thus we want this:
> >>>
> >>> f <- function(x) x
> >>> g <- function(x) invisible(x)
> >>>
> F(f, 1)
> >>> 2
> >>>
> F(g, 1)
> >> I don't think there's a way to do that. Internally there's a global
> >> flag called R_Visible; if it is set to zero, the value won't print. But
> >> it gets reset to 1 very easily (e.g. by adding 1 to the result of an
> >> invisible function), and it's not available in the API for you to write
> >> C code to look at it.
> >>
> >> I think you'll just have to do require the user of your F to tell you
> >> that they want the result to be invisible.
> >>
> >> Duncan Murdoch
> >>
> >
> > Perhaps R_Visible be made available at the R level in the future.
> > It would be helpful in situations where you are transforming a
> > function but want to keep aspects of it such as whether the
> > return result is invisible.
>
> Actually, there is a way, but it's undocumented (i.e., use at your own
> risk). It's the eval.with.vis function. This is an internal function
> that is used within source() and capture.output(); you'll have to guess
> from the usage there what the args are. But here's an F that does
> something close to what you want:
>
> > fix(F)
> > f <- function() 1
> > g <- function() invisible(1)
> >
> > F <- function (expr)
> + {
> + expr <- substitute(expr)
> + pf <- parent.frame()
> + tmp <- .Internal(eval.with.vis(expr, pf,
> + baseenv()))
> + tmp
> + }
> > F(f())
> $value
> [1] 1
>
> $visible
> [1] TRUE
>
> > F(g())
> $value
> [1] 1
>
> $visible
> [1] FALSE
>
>
Perfect. Thanks
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
> On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
[...]
>> Actually, there is a way, but it's undocumented (i.e., use at your own
>> risk). It's the eval.with.vis function. This is an internal function
Yes... and there are three problems here:
1) To spot the undocumented function one is looking for,
2) To figure out how to use it,
3) To rewrite your code regularly if you maintain packages that use
several of such undocumented functions. This is the case of many R GUI
projects... and one reason why staying up-to-date with the new versions
of R (every 6 months) is a nightmare for these GUIs!
For instance, I use eval.with.vis() in the latest version of svSockets
package in the SciViews bundle, but I am afraid to release it on CRAN
because I know of the nightware I will face if this function (silently)
changes its behavior in subsequent versions of R.
I guess there is no solution to this problem, since there is certainly a
good reason for keeping portions of R code undocumented (and thus
flagged as :" use-it-at-your-own-risk!"), but it does not eases our life!
Best,
Philippe Grosjean
>> that is used within source() and capture.output(); you'll have to guess
>> from the usage there what the args are. But here's an F that does
>> something close to what you want:
>>
>> > fix(F)
>> > f <- function() 1
>> > g <- function() invisible(1)
>> >
>> > F <- function (expr)
>> + {
>> + expr <- substitute(expr)
>> + pf <- parent.frame()
>> + tmp <- .Internal(eval.with.vis(expr, pf,
>> + baseenv()))
>> + tmp
>> + }
>> > F(f())
>> $value
>> [1] 1
>>
>> $visible
>> [1] TRUE
>>
>> > F(g())
>> $value
>> [1] 1
>>
>> $visible
>> [1] FALSE
>>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] attachments on R mailing lists
> "Michael" == Michael Toews <[EMAIL PROTECTED]> > on Wed, 25 Oct 2006 19:00:03 -0700 writes: Michael> Okay ... I'll try to attach that patch once more Michael> ... (does this list only accept certain exertions Michael> for attachments? I used '.patch', but it must have Michael> been filtered off, so I'll try '.patch.txt' now It's not the file name, but the MIME type of an attachment which is important. text/plain is valid, e.g., The posting guide and even http://www.r-project.org/mail.html mention this. It seems your e-mail software does not allow to specify the MIME type used, but rather determines it from the file extension. Other e-mail client programs send all "unknown" attachments" as binary; and most ascii texts seem "unknown" in this regard. All this feels Micro$oftish and it is sad to see that such a softie--attitude also invades free software developments such as a unix-based version Thunderbird which I'm guessing you use. Regards, Martin Maechler, ETH Zurich (R mailing list manager) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/26/06, Philippe Grosjean <[EMAIL PROTECTED]> wrote:
>
>
> > On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> [...]
> >> Actually, there is a way, but it's undocumented (i.e., use at your own
> >> risk). It's the eval.with.vis function. This is an internal function
>
> Yes... and there are three problems here:
> 1) To spot the undocumented function one is looking for,
> 2) To figure out how to use it,
> 3) To rewrite your code regularly if you maintain packages that use
> several of such undocumented functions. This is the case of many R GUI
> projects... and one reason why staying up-to-date with the new versions
> of R (every 6 months) is a nightmare for these GUIs!
>
> For instance, I use eval.with.vis() in the latest version of svSockets
> package in the SciViews bundle, but I am afraid to release it on CRAN
> because I know of the nightware I will face if this function (silently)
> changes its behavior in subsequent versions of R.
>
> I guess there is no solution to this problem, since there is certainly a
> good reason for keeping portions of R code undocumented (and thus
> flagged as :" use-it-at-your-own-risk!"), but it does not eases our life!
>
> Best,
>
> Philippe Grosjean
>
> >> that is used within source() and capture.output(); you'll have to guess
> >> from the usage there what the args are. But here's an F that does
> >> something close to what you want:
> >>
> >> > fix(F)
> >> > f <- function() 1
> >> > g <- function() invisible(1)
> >> >
> >> > F <- function (expr)
> >> + {
> >> + expr <- substitute(expr)
> >> + pf <- parent.frame()
> >> + tmp <- .Internal(eval.with.vis(expr, pf,
> >> + baseenv()))
> >> + tmp
> >> + }
> >> > F(f())
> >> $value
> >> [1] 1
> >>
> >> $visible
> >> [1] TRUE
> >>
> >> > F(g())
> >> $value
> >> [1] 1
> >>
> >> $visible
> >> [1] FALSE
> >>
> >>
>
>
I will be using it in the next version of the gsubfn package and am also
considering it for an application in the dyn package too so that makes
two or three packages already. I think it would be a good idea to make it
or equivalent generally available in R.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/26/2006 6:28 AM, Philippe Grosjean wrote:
>
>> On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> [...]
>>> Actually, there is a way, but it's undocumented (i.e., use at your own
>>> risk). It's the eval.with.vis function. This is an internal function
>
> Yes... and there are three problems here:
> 1) To spot the undocumented function one is looking for,
> 2) To figure out how to use it,
> 3) To rewrite your code regularly if you maintain packages that use
> several of such undocumented functions. This is the case of many R GUI
> projects... and one reason why staying up-to-date with the new versions
> of R (every 6 months) is a nightmare for these GUIs!
Those are definitely real problems.
At the last useR meeting, Thomas Baier made an excellent suggestion:
someone should put together an API specifically for R GUIs. I think
eval.with.vis would have to be part of such an API; there are dozens of
other currently undocumented or unavailable functions as well.
This is a difficult project, because it would have to get agreement on
what should be part of the API, and that will constrain future changes:
so there would be a lot of resistance to making it too constraining.
It will need to be flexible, so that R isn't required to supply services
that don't make sense in all contexts.
Duncan Murdoch
> For instance, I use eval.with.vis() in the latest version of svSockets
> package in the SciViews bundle, but I am afraid to release it on CRAN
> because I know of the nightware I will face if this function (silently)
> changes its behavior in subsequent versions of R.
>
> I guess there is no solution to this problem, since there is certainly a
> good reason for keeping portions of R code undocumented (and thus
> flagged as :" use-it-at-your-own-risk!"), but it does not eases our life!
>
> Best,
>
> Philippe Grosjean
>
>>> that is used within source() and capture.output(); you'll have to guess
>>> from the usage there what the args are. But here's an F that does
>>> something close to what you want:
>>>
>>> > fix(F)
>>> > f <- function() 1
>>> > g <- function() invisible(1)
>>> >
>>> > F <- function (expr)
>>> + {
>>> + expr <- substitute(expr)
>>> + pf <- parent.frame()
>>> + tmp <- .Internal(eval.with.vis(expr, pf,
>>> + baseenv()))
>>> + tmp
>>> + }
>>> > F(f())
>>> $value
>>> [1] 1
>>>
>>> $visible
>>> [1] TRUE
>>>
>>> > F(g())
>>> $value
>>> [1] 1
>>>
>>> $visible
>>> [1] FALSE
>>>
>>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
Perhaps there could be a set of functions that are made available
without the promise of future compatibility but with the promise
that they will change less frequently than if they were not documented
and if they are changed the changes will be highlighted
to make it easier for the users of the API to know about such
changes. That might overcome resistance stemming from the
fear of prematurely setting design decisions in stone.
On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 10/26/2006 6:28 AM, Philippe Grosjean wrote:
> >
> >> On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> > [...]
> >>> Actually, there is a way, but it's undocumented (i.e., use at your own
> >>> risk). It's the eval.with.vis function. This is an internal function
> >
> > Yes... and there are three problems here:
> > 1) To spot the undocumented function one is looking for,
> > 2) To figure out how to use it,
> > 3) To rewrite your code regularly if you maintain packages that use
> > several of such undocumented functions. This is the case of many R GUI
> > projects... and one reason why staying up-to-date with the new versions
> > of R (every 6 months) is a nightmare for these GUIs!
>
> Those are definitely real problems.
>
> At the last useR meeting, Thomas Baier made an excellent suggestion:
> someone should put together an API specifically for R GUIs. I think
> eval.with.vis would have to be part of such an API; there are dozens of
> other currently undocumented or unavailable functions as well.
>
> This is a difficult project, because it would have to get agreement on
> what should be part of the API, and that will constrain future changes:
> so there would be a lot of resistance to making it too constraining.
> It will need to be flexible, so that R isn't required to supply services
> that don't make sense in all contexts.
>
> Duncan Murdoch
>
> > For instance, I use eval.with.vis() in the latest version of svSockets
> > package in the SciViews bundle, but I am afraid to release it on CRAN
> > because I know of the nightware I will face if this function (silently)
> > changes its behavior in subsequent versions of R.
> >
> > I guess there is no solution to this problem, since there is certainly a
> > good reason for keeping portions of R code undocumented (and thus
> > flagged as :" use-it-at-your-own-risk!"), but it does not eases our life!
> >
> > Best,
> >
> > Philippe Grosjean
> >
> >>> that is used within source() and capture.output(); you'll have to guess
> >>> from the usage there what the args are. But here's an F that does
> >>> something close to what you want:
> >>>
> >>> > fix(F)
> >>> > f <- function() 1
> >>> > g <- function() invisible(1)
> >>> >
> >>> > F <- function (expr)
> >>> + {
> >>> + expr <- substitute(expr)
> >>> + pf <- parent.frame()
> >>> + tmp <- .Internal(eval.with.vis(expr, pf,
> >>> + baseenv()))
> >>> + tmp
> >>> + }
> >>> > F(f())
> >>> $value
> >>> [1] 1
> >>>
> >>> $visible
> >>> [1] TRUE
> >>>
> >>> > F(g())
> >>> $value
> >>> [1] 1
> >>>
> >>> $visible
> >>> [1] FALSE
> >>>
> >>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] attachments on R mailing lists
On 26-Oct-06 Martin Maechler wrote: > >> "Michael" == Michael Toews <[EMAIL PROTECTED]> >> on Wed, 25 Oct 2006 19:00:03 -0700 writes: > > Michael> Okay ... I'll try to attach that patch once more > Michael> ... (does this list only accept certain exertions > Michael> for attachments? I used '.patch', but it must have > Michael> been filtered off, so I'll try '.patch.txt' now > > It's not the file name, but the MIME type of an attachment which > is important. > text/plain is valid, e.g., > > The posting guide and even http://www.r-project.org/mail.html > mention this. > > It seems your e-mail software does not allow to specify the MIME > type used, but rather determines it from the file extension. > Other e-mail client programs send all "unknown" attachments" as > binary; and most ascii texts seem "unknown" in this regard. Mine (XFMail) always gives me the option to confirm or change the MIME type it has determined from the extension or, if it does not recognise the extension, I am asked to assign the MIME type. > All this feels Micro$oftish and it is sad to see that such a > softie--attitude also invades free software developments such > as a unix-based version Thunderbird which I'm guessing you use. I have to agree with this. Quite apart from any criticisms one may have of the quality of technical performance of M$ software, one of its major annoyances since its early days has been its tendency to "know better" than the user, and to assume control over choices which the user would prefer to make judiciously. One outstanding quality of Unix, and later Linux, is the fact that the user can consciously choose and control what the software does. Regrettably, Linux increasingly conceals this beneath "user-friendly" interfaces which take control, softie-style. This is undoubtedly an attempt to appeal to a wider user-base. Fortunately, the underlying controllability is still accessible in many cases if you lift the lid. But GUI-driven applications such as web-browsers and web-based mailers tend to work from the top (GUI) down, making this hard to reach. Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 26-Oct-06 Time: 12:56:22 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
Duncan Murdoch wrote:
[...]
> At the last useR meeting, Thomas Baier made an excellent suggestion:
> someone should put together an API specifically for R GUIs. I think
> eval.with.vis would have to be part of such an API; there are dozens of
> other currently undocumented or unavailable functions as well.
Ah, ha! I am very happy to discover that Thomas Baier had this excellent
idea at the last useR meeting. It is almost four years that I claims for
a R GUI API. If you look at the manual that comes with the SciViews
bundle (available on CRAN), you will notice that there is a manual
called 'SciViews-R, A GUI API and a suite of application for R' (see
http://www.sciviews.org/SciViews-R/Manual.pdf) with about 50 pages that
discuss several aspects related to R GUI APIs.
There are also threads in the R Wiki that discusses a similar topic
(although more related to graphical widgets):
http://wiki.r-project.org/rwiki/doku.php?id=developers:iwidgets&s=api,
http://wiki.r-project.org/rwiki/doku.php?id=developers:gwidgets_api.
This is mainly the work of John Versani, after a discussion between Him,
Simon Urbanek (iWidgets), Michael Lawrence (RGtk2), and myself (SciViews).
That said, I did several attempt to put all people at R-SIG-GUI around a
table to define a common R GUI API,... and I got no significant echo.
So, I personally give up with this topic and look at what others,
perhaps stronger than me in R programming or in communication with other
developers, will do.
But, please, do not give credit for "first idea" to someone else on such
a topic... It is long enough that I fight for better R GUIs (for
instance, http://www.r-project.org/GUI), that this looks offending to me!
Best,
Philippe Grosjean
> This is a difficult project, because it would have to get agreement on
> what should be part of the API, and that will constrain future changes:
> so there would be a lot of resistance to making it too constraining. It
> will need to be flexible, so that R isn't required to supply services
> that don't make sense in all contexts.
>
> Duncan Murdoch
>
>> For instance, I use eval.with.vis() in the latest version of svSockets
>> package in the SciViews bundle, but I am afraid to release it on CRAN
>> because I know of the nightware I will face if this function
>> (silently) changes its behavior in subsequent versions of R.
>>
>> I guess there is no solution to this problem, since there is certainly
>> a good reason for keeping portions of R code undocumented (and thus
>> flagged as :" use-it-at-your-own-risk!"), but it does not eases our life!
>>
>> Best,
>>
>> Philippe Grosjean
>>
that is used within source() and capture.output(); you'll have to guess
from the usage there what the args are. But here's an F that does
something close to what you want:
> fix(F)
> f <- function() 1
> g <- function() invisible(1)
>
> F <- function (expr)
+ {
+ expr <- substitute(expr)
+ pf <- parent.frame()
+ tmp <- .Internal(eval.with.vis(expr, pf,
+ baseenv()))
+ tmp
+ }
> F(f())
$value
[1] 1
$visible
[1] TRUE
> F(g())
$value
[1] 1
$visible
[1] FALSE
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.missing
I don't see how this solves the problem.
> as.missing <- force
> f <- function(y, x=1) {cat(missing(x)) ; x}
> g <- function(x) f(3,x)
> g(1)
FALSE[1] 1
> g()
TRUEError in f(3, x) : argument "x" is missing, with no default
I think I still have to put all the logic in g() to figure out if the
argument is missing, rather than the nice clean solution of just passing
the argument along to the function it calls. How does this differ from
the problem I already have when I specifying the argument as NULL and
do all the checking in g?
Paul
Gabor Grothendieck wrote:
> You can do it like this:
>
>> as.missing <- force
>> g <- function(x = as.missing()) missing(x)
>> g(3)
>
> [1] FALSE
>
>> g()
>
> [1] TRUE
>
> On 10/24/06, Paul Gilbert <[EMAIL PROTECTED]> wrote:
>
>> (I'm not sure if this is a request for a feature, or another instance
>> where a feature has eluded me for many years.)
>>
>> Often I have a function which calls other functions, and may often use
>> the default arguments to those functions, but needs the capability to
>> pass along non-default choices. I usually do this with some variation on
>>
>> foo <- function(x, foo2Args=NULL or a list(foo2defaults),
>>foo3Args=NULL or a list(foo3defaults))
>>
>> and then have logic to check for NULL, or use the list in combination
>> with do.call. It is also possible to do this with ..., but it always
>> seems a bit dangerous passing all the unnamed arguments along to all the
>> functions being called, especially when I always seem to be calling
>> functions that have similar arguments (maxit, eps, start, frequency,
>> etc).
>>
>> It is a situation I have learned to live with, but one of my
>> co-maintainers just pointed out to me that there should be a good way to
>> do this in R. Perhaps there is something else I have missed all these
>> years? Is there a way to do this cleanly? It would be nice to have
>> something like
>>
>> foo <- function(x, foo2Args=as.missing(), foo3Args=as.missing())
>>
>> then the call to foo2 and foo3 could specify foo2Args and foo3Args, but
>> these would get treated as if they were missing, unless they are given
>> other values.
>>
>> Paul Gilbert
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: invalid multibyte string
On Thu, 26 Oct 2006, Henrik Bengtsson wrote:
> I'm observing the following on different platforms:
>
>> parse(text='"\\x7F"')
> expression("\177")
>> parse(text='"\\x80"')
> Error: invalid multibyte string
Yes. It's an invalid multibyte string. In UTF-8 a single byte is a valid
character string only if it is below x80, so x7F is fine but x80 is not.
In fact x80 is not the leading byte of any valid UTF-8 character.
You have to work out what the Unicode code point is for whatever character
you were expecting to be x80 and convert that to UTF-8.
I'm surprised that one of your UTF-8 machines worked -- I don't think it
should.
-thomas
> ...
>> parse(text='"\\xFF"')
> Error: invalid multibyte string
>
> However,
>
> cat("\x7F\n\x80\n...\xFF\n")
>
> works. Using R --vanilla.
> SYSTEMS GIVING THE ERROR:
>> sessionInfo()
> R version 2.4.0 (2006-10-03)
> x86_64-unknown-linux-gnu
> locale:
> LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=en_AU.UTF-8;LC_MESSAGES=en_AU.UTF-8;LC_PAPER=en_AU.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_AU.UTF-8;LC_IDENTIFICATION=C
>
> R version 2.4.0 Patched (2006-10-03 r39576)
> i686-pc-linux-gnu
> locale:
> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>
>
> SYSTEMS OK:
> R version 2.4.0 Under development (unstable) (2006-07-23 r38687)
> x86_64-unknown-linux-gnu
> locale:
> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>
> R version 2.4.0 (2006-10-03)
> i386-pc-mingw32
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> R version 2.4.0 Patched (2006-10-10 r39600)
> i386-pc-mingw32
> locale:
> LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=En
> glish_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> Version 2.3.0 (2006-04-24)
> x86_64-unknown-linux-gnu
> locale:
>
>
> All of the above have the following packages attached:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> We identified this problem because R CMD check complained:
>
>> * checking package dependencies ... WARNING
>> Error in deparse(e[[2]]) : invalid multibyte string
>> Execution halted
>
> because we use "\xFF" (or "\377") in the source code to be used as a
> terminator in a vector buffer; "\0" can't be used for other reasons.
>
> Is the above a bug in R or one in my head?
>
> /H
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: invalid multibyte string
Thomas Lumley <[EMAIL PROTECTED]> writes:
> On Thu, 26 Oct 2006, Henrik Bengtsson wrote:
>
> > I'm observing the following on different platforms:
> >
> >> parse(text='"\\x7F"')
> > expression("\177")
> >> parse(text='"\\x80"')
> > Error: invalid multibyte string
>
> Yes. It's an invalid multibyte string. In UTF-8 a single byte is a valid
> character string only if it is below x80, so x7F is fine but x80 is not.
> In fact x80 is not the leading byte of any valid UTF-8 character.
>
> You have to work out what the Unicode code point is for whatever character
> you were expecting to be x80 and convert that to UTF-8.
>
> I'm surprised that one of your UTF-8 machines worked -- I don't think it
> should.
Interestingly, we can parse, but not print or deparse:
> x<-parse(text='"\\x80"')
> x
Error: invalid multibyte string
> z <- deparse(x)
Error in deparse(x) : invalid multibyte string
> cat(x[[1]])
�>
(the last line has a funny little cedilla-like symbol in pos 1)
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA handling in as.character applied to a list
Peter Dalgaard <[EMAIL PROTECTED]> writes:
> Hmm...
>
>> as.character(v)
> [1] NA "NA" "NA"
>
> This does look like a leftover from times when there was no character
> NA in the language. It is the kind of thing you need to be very
> careful about fixing though. (I have a couple of scars from
> as.character on formulas when introducing backtick quoting.)
Well, I guess that's an argument for leaving the inconsistent
behavior. In case there is interest in fixing, here is a patch I was
playing with. It doesn't address the nasties with dput.
index 8eec5c3..787c230 100644
--- a/src/main/coerce.c
+++ b/src/main/coerce.c
@@ -1041,6 +1041,14 @@ #if 0
else if (isSymbol(VECTOR_ELT(v, i)))
SET_STRING_ELT(rval, i, PRINTNAME(VECTOR_ELT(v, i)));
#endif
+else if ((length(VECTOR_ELT(v, i)) == 1) &&
+ (isInteger(VECTOR_ELT(v, i)) ||
+ isReal(VECTOR_ELT(v, i)) ||
+ isLogical(VECTOR_ELT(v, i {
+SET_STRING_ELT(rval, i,
+ STRING_ELT(coerceVector(VECTOR_ELT(v, i),
+ STRSXP), 0));
+}
else
SET_STRING_ELT(rval, i,
STRING_ELT(deparse1line(VECTOR_ELT(v, i), 0),
0));
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On Wed, 25 Oct 2006, Duncan Murdoch wrote: > On 10/25/2006 8:14 PM, Gabor Grothendieck wrote: > > Suppose we have a function such as the following > > > > F <- function(f, x) f(x)+1 > > > > which runs function f and then transforms it. I would like the > > corresponding function which works the same except that > > unlike F returns an invisible result if and only if f does. > > I don't think there's a way to do that. Internally there's a global > flag called R_Visible; if it is set to zero, the value won't print. But > it gets reset to 1 very easily (e.g. by adding 1 to the result of an > invisible function), and it's not available in the API for you to write > C code to look at it. source(print.eval=TRUE) appears to do this by using an eval.with.vis() function that calls a .Internal(): eval.with.vis <- function(expr, envir = parent.frame(), enclos = if (is.list(envir) || is.pairlist(envir)) parent.frame() else baseenv()) .Internal(eval.with.vis(expr, envir, enclos)) Perhaps that could be adapted for more general use. Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 pb in R 2.5.0
Hi,
When playing interactively with the S4 system, I've tried
to define the following class:
> setClass("A", representation("integer"))
[1] "A"
> showClass("A")
Slots:
Name:.Data
Class: integer
Extends:
Class "integer", from data part
Class "vector", by class "integer", distance 2
Class "numeric", by class "integer", distance 2
then I realized that I made a typo (I don't want to extend
the "integer" type) so I redefined class A:
> setClass("A", representation(toto="integer"))
> showClass("A")
Slots:
Name: toto
Class: integer
Now if I try to extend A:
> setClass("Aa", representation("A"))
Error in reconcilePropertiesAndPrototype(name, slots, prototype,
superClasses, :
"A" is not eligible to be the data part of another class
(must be a basic class or a virtual class with no slots)
Surprising. And even more surprising: I don't get this if I don't
try to define class A twice or if I invert the order of the 2 calls
to setClass("A", ...)!
> sessionInfo()
R version 2.4.0 (2006-10-03)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils"
"datasets"
[7] "base"
No problem with R-2.4.0.
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pb with .findInheritedMethods
Hi again,
Here is a very simplified version of a class hierarchy
defined in the Biobase package (Bioconductor). I post
here because this seems to be an S4 related problem:
setClass("A", representation(name="character"))
setMethod("initialize", "A", function(.Object) [EMAIL PROTECTED] <- "I'm
an A"; .Object})
setClass("Ab", contains="A")
setMethod("initialize", "Ab", function(.Object) callNextMethod(.Object))
setClass("Abc", contains="Ab")
setClass("Abcd", contains = c("Abc"))
Now if I do:
tmp1 <- new("Abc")
tmp2 <- new("Abcd")
I get the following warning:
Warning message:
Ambiguous method selection for "initialize", target "Abcd" (the
first of the signatures shown will be used)
Abc
Ab
in: .findInheritedMethods(classes, fdef, mtable)
I don't really understand why .findInheritedMethods is
complaining here...
And if I don't do 'tmp1 <- new("Abc")' before I
do 'tmp2 <- new("Abcd")', then I don't get the warning
anymore!
Does anybody have an explanation for this?
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/26/2006 10:29 AM, Philippe Grosjean wrote: > But, please, do not give credit for "first idea" to someone else on such > a topic... It is long enough that I fight for better R GUIs (for > instance, http://www.r-project.org/GUI), that this looks offending to me! Sorry, I didn't mean to claim that he's the first one to think of this, just that he did bring it up recently, and that it's an excellent idea. I think the fact that we don't have a GUI API is support for my statement that it's a difficult project. Not all the difficulties are technical. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/26/2006 7:12 AM, Gabor Grothendieck wrote:
> Perhaps there could be a set of functions that are made available
> without the promise of future compatibility but with the promise
> that they will change less frequently than if they were not documented
> and if they are changed the changes will be highlighted
> to make it easier for the users of the API to know about such
> changes. That might overcome resistance stemming from the
> fear of prematurely setting design decisions in stone.
Actually, I think that's about as much of a guarantee as things that are
set in stone get. R is built of soft stone :-).
Duncan Murdoch
>
> On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> On 10/26/2006 6:28 AM, Philippe Grosjean wrote:
On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>>> [...]
> Actually, there is a way, but it's undocumented (i.e., use at your own
> risk). It's the eval.with.vis function. This is an internal function
>>> Yes... and there are three problems here:
>>> 1) To spot the undocumented function one is looking for,
>>> 2) To figure out how to use it,
>>> 3) To rewrite your code regularly if you maintain packages that use
>>> several of such undocumented functions. This is the case of many R GUI
>>> projects... and one reason why staying up-to-date with the new versions
>>> of R (every 6 months) is a nightmare for these GUIs!
>> Those are definitely real problems.
>>
>> At the last useR meeting, Thomas Baier made an excellent suggestion:
>> someone should put together an API specifically for R GUIs. I think
>> eval.with.vis would have to be part of such an API; there are dozens of
>> other currently undocumented or unavailable functions as well.
>>
>> This is a difficult project, because it would have to get agreement on
>> what should be part of the API, and that will constrain future changes:
>> so there would be a lot of resistance to making it too constraining.
>> It will need to be flexible, so that R isn't required to supply services
>> that don't make sense in all contexts.
>>
>> Duncan Murdoch
>>
>>> For instance, I use eval.with.vis() in the latest version of svSockets
>>> package in the SciViews bundle, but I am afraid to release it on CRAN
>>> because I know of the nightware I will face if this function (silently)
>>> changes its behavior in subsequent versions of R.
>>>
>>> I guess there is no solution to this problem, since there is certainly a
>>> good reason for keeping portions of R code undocumented (and thus
>>> flagged as :" use-it-at-your-own-risk!"), but it does not eases our life!
>>>
>>> Best,
>>>
>>> Philippe Grosjean
>>>
> that is used within source() and capture.output(); you'll have to guess
> from the usage there what the args are. But here's an F that does
> something close to what you want:
>
> > fix(F)
> > f <- function() 1
> > g <- function() invisible(1)
> >
> > F <- function (expr)
> + {
> + expr <- substitute(expr)
> + pf <- parent.frame()
> + tmp <- .Internal(eval.with.vis(expr, pf,
> + baseenv()))
> + tmp
> + }
> > F(f())
> $value
> [1] 1
>
> $visible
> [1] TRUE
>
> > F(g())
> $value
> [1] 1
>
> $visible
> [1] FALSE
>
>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 pb in R 2.5.0
Herve Pages wrote: > ... > > > sessionInfo() > R version 2.4.0 (2006-10-03) > x86_64-unknown-linux-gnu > > locale: > > LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C > > attached base packages: > [1] "methods" "stats" "graphics" "grDevices" "utils" > "datasets" > [7] "base" > oops, please replace by > sessionInfo() R version 2.5.0 Under development (unstable) (2006-10-20 r39686) x86_64-unknown-linux-gnu locale: LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" sorry, > No problem with R-2.4.0. > This is still true. H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with .findInheritedMethods
Hi again,
This happens with R-2.4.0 and R-devel.
Cheers,
H.
Herve Pages wrote:
> Hi again,
>
>
> Here is a very simplified version of a class hierarchy
> defined in the Biobase package (Bioconductor). I post
> here because this seems to be an S4 related problem:
>
> setClass("A", representation(name="character"))
> setMethod("initialize", "A", function(.Object) [EMAIL PROTECTED] <- "I'm
> an A"; .Object})
>
> setClass("Ab", contains="A")
> setMethod("initialize", "Ab", function(.Object) callNextMethod(.Object))
>
> setClass("Abc", contains="Ab")
>
> setClass("Abcd", contains = c("Abc"))
>
> Now if I do:
>
> tmp1 <- new("Abc")
> tmp2 <- new("Abcd")
>
> I get the following warning:
>
> Warning message:
> Ambiguous method selection for "initialize", target "Abcd" (the
> first of the signatures shown will be used)
> Abc
> Ab
> in: .findInheritedMethods(classes, fdef, mtable)
>
> I don't really understand why .findInheritedMethods is
> complaining here...
> And if I don't do 'tmp1 <- new("Abc")' before I
> do 'tmp2 <- new("Abcd")', then I don't get the warning
> anymore!
>
> Does anybody have an explanation for this?
>
>
> Thanks,
> H.
>
> __
> 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] as.missing
This is what I get:
> as.missing <- force
> f <- function(y, x=1) {cat(missing(x)) ; x}
> g <- function(x=as.missing()) f(3,x)
> g()
FALSEError in as.missing() : argument "x" is missing, with no default
> traceback()
3: as.missing()
2: f(3, x)
1: g()
> traceback()
3: as.missing()
2: f(3, x)
1: g()
so g did in fact pass the missing to f and it was only f that blew up,
not g. If that's not what you want please explain.
On 10/26/06, Paul Gilbert <[EMAIL PROTECTED]> wrote:
> I don't see how this solves the problem.
>
> > as.missing <- force
> > f <- function(y, x=1) {cat(missing(x)) ; x}
> > g <- function(x) f(3,x)
> > g(1)
> FALSE[1] 1
> > g()
> TRUEError in f(3, x) : argument "x" is missing, with no default
>
> I think I still have to put all the logic in g() to figure out if the
> argument is missing, rather than the nice clean solution of just passing
> the argument along to the function it calls. How does this differ from
> the problem I already have when I specifying the argument as NULL and
> do all the checking in g?
>
> Paul
>
> Gabor Grothendieck wrote:
>
> > You can do it like this:
> >
> >> as.missing <- force
> >> g <- function(x = as.missing()) missing(x)
> >> g(3)
> >
> > [1] FALSE
> >
> >> g()
> >
> > [1] TRUE
> >
> > On 10/24/06, Paul Gilbert <[EMAIL PROTECTED]> wrote:
> >
> >> (I'm not sure if this is a request for a feature, or another instance
> >> where a feature has eluded me for many years.)
> >>
> >> Often I have a function which calls other functions, and may often use
> >> the default arguments to those functions, but needs the capability to
> >> pass along non-default choices. I usually do this with some variation on
> >>
> >> foo <- function(x, foo2Args=NULL or a list(foo2defaults),
> >>foo3Args=NULL or a list(foo3defaults))
> >>
> >> and then have logic to check for NULL, or use the list in combination
> >> with do.call. It is also possible to do this with ..., but it always
> >> seems a bit dangerous passing all the unnamed arguments along to all the
> >> functions being called, especially when I always seem to be calling
> >> functions that have similar arguments (maxit, eps, start, frequency,
> >> etc).
> >>
> >> It is a situation I have learned to live with, but one of my
> >> co-maintainers just pointed out to me that there should be a good way to
> >> do this in R. Perhaps there is something else I have missed all these
> >> years? Is there a way to do this cleanly? It would be nice to have
> >> something like
> >>
> >> foo <- function(x, foo2Args=as.missing(), foo3Args=as.missing())
> >>
> >> then the call to foo2 and foo3 could specify foo2Args and foo3Args, but
> >> these would get treated as if they were missing, unless they are given
> >> other values.
> >>
> >> Paul Gilbert
> >
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential info...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: invalid multibyte string
In Section "Package subdirectories" in "Writing R Extensions" [2.4.0
(2006-10-10)] it says:
"Only ASCII characters (and the control characters tab, formfeed, LF
and CR) should be used in code files. Other characters are accepted in
comments, but then the comments may not be readable in e.g. a UTF-8
locale. Non-ASCII characters in object names will normally [1] fail
when the package is installed. Any byte will be allowed [2] in a
quoted character string (but \u escapes should not be used), but
non-ASCII character strings may not be usable in some locales and may
display incorrectly in others.", where the footnote [2] reads "It is
good practice to encode them as octal or hex escape sequences".
(Note: ASCII refers (correctly) to the 7-bit ASCII [0-127] and none of
the 8-bit ASCII extensions [128-255].)
According to sentense about quoted strings, the following R/*.R code
should still be valid:
pads <- sapply(0:64, FUN=function(x) paste(rep("\xFF", x), collapse=""));
or as we first had:
pads <- sapply(0:64, FUN=function(x) paste(rep("\377", x), collapse=""));
Is R CMD check, or more precisely
tools:::.check_packages_used(dir=\"${pkgdir}\") in (perl script
bin/check) too picky? In check_packages_used() there is an internal
function find_bad_exprs() trying to identify "bad expressions", and it
is when it tries to deparse() the above parse():ed code it complains.
This is exactly what Peter pointed out in his example.
Cheers
Henrik
On 26 Oct 2006 18:43:45 +0200, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> Thomas Lumley <[EMAIL PROTECTED]> writes:
>
> > On Thu, 26 Oct 2006, Henrik Bengtsson wrote:
> >
> > > I'm observing the following on different platforms:
> > >
> > >> parse(text='"\\x7F"')
> > > expression("\177")
> > >> parse(text='"\\x80"')
> > > Error: invalid multibyte string
> >
> > Yes. It's an invalid multibyte string. In UTF-8 a single byte is a valid
> > character string only if it is below x80, so x7F is fine but x80 is not.
> > In fact x80 is not the leading byte of any valid UTF-8 character.
> >
> > You have to work out what the Unicode code point is for whatever character
> > you were expecting to be x80 and convert that to UTF-8.
> >
> > I'm surprised that one of your UTF-8 machines worked -- I don't think it
> > should.
>
> Interestingly, we can parse, but not print or deparse:
>
> > x<-parse(text='"\\x80"')
> > x
> Error: invalid multibyte string
> > z <- deparse(x)
> Error in deparse(x) : invalid multibyte string
> > cat(x[[1]])
> �>
>
> (the last line has a funny little cedilla-like symbol in pos 1)
>
> --
>O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] improperly persisting dialog after Source... on Macintel (PR#9318)
Full_Name: Allan Drummond Version: 2.3.1 OS: Mac OS X 10.4.8 Submission from: (NULL) (65.96.163.97) When a file is sourced as the first, or near the first, step using R Gui on Intel Macbook Pro running OS X 10.4.8, the "R File to Source" dialog reappears upon switching away from and back to R Gui. Using Intel Mac, steps are: 1) Open R Gui with at least one other application open 2) As first command, Source... a file (either cmd-shift-O or use menu), choosing from dialog box. Contents of file seem irrelevant. Upon choosing the file, the dialog should disappear as expected 3) Cmd-Tab to another open application 4) Cmd-Tab back to R. 5) "R File to Source" dialog reappears. Now, it cannot be dismissed by Cancel button, nor by any other means that I can detect. Contents are non-interactive. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
