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
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-
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()
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", representat
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_ME
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
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 clai
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] <-
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
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 s
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
> a
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 multiby
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
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 th
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 func
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 a
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 AP
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
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 the
> "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
> 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
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 <- functio
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 fin
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 compi
24 matches
Mail list logo
