Full_Name: Fernando Henrique Ferraz Pereira da Rosa
Version: 1.8.0
OS: Linux 2.4.21
Submission from: (NULL) (200.206.211.169)
After installing R 1.8.0, the R DBI interface stopped working. I tracked it
down as a problem in the 'methods' package, that comes in the default
installation.
S
Although I still have to look into the various flags, the IBM vacpp
(C and C++) and xlf (FORTRAN) compilers can be used to build
at least R.bin. Of course libR.dylib and the various bundles are
more complicated, but R.bin runs (in as far as it does not depend
on any modules and packages).
This is i
On Fri, 10 Oct 2003 21:01:07 -0500 (CDT), you wrote:
>On the other hand, having lazy evaluation makes other things simpler:
>there is no need for special operators, macros or other such stuff;
>everything can be done with ordinary functions. if, for, try,
>on.exit, switch are just functions. Some
On Fri, 10 Oct 2003, Duncan Murdoch wrote:
> On Fri, 10 Oct 2003 14:35:42 +0200, you wrote:
>
> >Saikat> This is most problematic when you are creating a
> >Saikat> generic for an existing function in base (as you
> >Saikat> very well could for log). This often makes the
> >Saikat
On Fri, 10 Oct 2003 14:35:42 +0200, you wrote:
>Saikat> This is most problematic when you are creating a
>Saikat> generic for an existing function in base (as you
>Saikat> very well could for log). This often makes the
>Saikat> ability to make new generics out of existing
>Saik
Needs a call to R_CheckUserInterrupt at the appropriate place. The
only platform that currently can interrupt a long print seems to be
Rgui on Windows because of an event poll in the console output
function. One possibility is to put in a check every 100 calls, say,
to Rvprintf in printutils.c.
Hi Saikat.
Nice. The more help we can get from the compiler, the
better. Registration provides the first step, and your macro(s)
provide an additional level. So it is highly desirable to have that if
people are manually creating the registration information.
When we put the registration technique
I initially sent this to the biocore mailing list - but it was
suggested that r-devel would also find it interesting.
Many of us use a macro like
#define CALL_DEF(fname, nargs) { #fname, (DL_FUNC)&fname, nargs}
for use in function registration for use with .Call.
For example, using the example
On Friday, Oct 10, 2003, at 08:35 US/Eastern, Martin Maechler wrote:
"Saikat" == Saikat DebRoy <[EMAIL PROTECTED]>
on Thu, 9 Oct 2003 11:41:01 -0400 writes:
Saikat> This is most problematic when you are creating a
Saikat> generic for an existing function in base (as you
Saikat> ver
On Fri, Oct 10, 2003 at 06:53:55AM -0700, Thomas Lumley wrote:
> On Fri, 10 Oct 2003, Chris Jackson wrote:
>
> > Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> > > Why do you need to edit PATH? I never have the rw10xx/bin directory
> > > in my Desktop PATH. I do set the PATH in a terminal window
On Fri, 10 Oct 2003, Chris Jackson wrote:
> Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> > Why do you need to edit PATH? I never have the rw10xx/bin directory
> > in my Desktop PATH. I do set the PATH in a terminal window when
> > working with R, but I do that via the shell startup options (.t
On Fri, 10 Oct 2003 [EMAIL PROTECTED] wrote:
> Full_Name: Jörg Polzehl
> Version: 1.8.0
> OS: Windows XP
> Submission from: (NULL) (62.141.176.1)
>
>
> I encountered a problem when playing with the mle library and specifying
> negative
> starting values for the parameters.
> The reason seems to
Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> Why do you need to edit PATH? I never have the rw10xx/bin directory
> in my Desktop PATH. I do set the PATH in a terminal window when
> working with R, but I do that via the shell startup options (.tcshrc
> in my case).
Emacs needs to know the locat
> "Saikat" == Saikat DebRoy <[EMAIL PROTECTED]>
> on Thu, 9 Oct 2003 11:41:01 -0400 writes:
Saikat> Function in the base library of R 1.8.0 seems to use
Saikat> a search path with base coming before the local
Saikat> environment. I think this is intentional and is
Saika
I've noticed this too (on Linux) and just considered it the price of
doing business. More than once I've hit Ctrl-Z and killed the process.
Not exactly a solution, though :)
-roger
Martin Maechler wrote:
NEWS for R 1.8.0 has
USER-VISIBLE CHANGES
<..>
o On Unix-like systems
Full_Name: Jörg Polzehl
Version: 1.8.0
OS: Windows XP
Submission from: (NULL) (62.141.176.1)
I encountered a problem when playing with the mle library and specifying
negative
starting values for the parameters.
The reason seems to be an incorrect behaviour of function formals:
glike<-function
Full_Name: Jörg Polzehl
Version: 1.8.0
OS: Windows XP
Submission from: (NULL) (62.141.176.1)
I encountered a problem when playing with the mle library and specifying
negative
starting values for the parameters.
The reason seems to be an incorrect behaviour of function formals:
glike<-function
Full_Name: Jörg Polzehl
Version: 1.8.0
OS: Windows XP
Submission from: (NULL) (62.141.176.1)
I encountered a problem when playing with the mle library and specifying
negative
starting values for the parameters.
The reason seems to be an incorrect behaviour of function formals:
glike<-function
Why do you need to edit PATH? I never have the rw10xx/bin directory in my
Desktop PATH. I do set the PATH in a terminal window when working with R,
but I do that via the shell startup options (.tcshrc in my case).
It is I believe possible to get the installer to do this, but it may well
not b
I'm having problems with seq.POSIXt() under R 1.8.0 (Windows NT4).
Essentially the last date in my sequence is lost depending on whether the
sequence spans a daylight saving time change.
This seems to apply regardless as to whether one uses by="DSTdays" or
by="days".
Try the following lines of
> Pfaff, Bernhard wrote:
>
> > Let me firstly thank the R Core Team for their tremendous efforts in
> > providing R 1.8.0. My following comment should therefore be
> understood as an
> > "fyi-only".
> >
> > I source compiled R 1.8.0 for windows with ATLAS (source
> compiled, too).
> > Everythi
Pfaff, Bernhard wrote:
Let me firstly thank the R Core Team for their tremendous efforts in
providing R 1.8.0. My following comment should therefore be understood as an
"fyi-only".
I source compiled R 1.8.0 for windows with ATLAS (source compiled, too).
Everything works fine and R is running flawl
I have just diligently upgraded my R installation for Windows XP Pro to
1.8.0. As an ESS user and R package builder, part of this upgrade process
for me always involves editing the PATH environment variable by hand to
update the location of the R bin directory.
Would it be possible or desirable f
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Maechler
> Sent: den 10 oktober 2003 12:26
> To: [EMAIL PROTECTED]
> Subject: [Rd] 1.8.0 on Unix: interrupting huge print()s ??
>
[snip]
> platforms. To reproduce, type
>
> cbind(1:1e6)
NEWS for R 1.8.0 has
>> USER-VISIBLE CHANGES
>>
>> <..>
>>
>> o On Unix-like systems interrupt signals now set a flag that is
>> checked periodically rather than calling longjmp from the
>> signal handler. This is analogous to the behavior on Windows.
>>
Let me firstly thank the R Core Team for their tremendous efforts in
providing R 1.8.0. My following comment should therefore be understood as an
"fyi-only".
I source compiled R 1.8.0 for windows with ATLAS (source compiled, too).
Everything works fine and R is running flawlessly! However, running
On Thu, 9 Oct 2003, John Chambers wrote:
> Prof Brian Ripley wrote:
> >
> > On Thu, 9 Oct 2003 [EMAIL PROTECTED] wrote:
> >
> > > The Complex group generic for S4 methods is not working:
> > >
> > > > setClass('foo', representation(z='complex'))
> > > [1] "foo"
> > > > setMethod('Complex', 'fo
27 matches
Mail list logo
