Duncan,
I see your point. But in that case Apache is the one managing the
life of the so, not R, and in many cases unloading the module would
also mean to unload R in which case the problem doesn't arise. Also
that general case requires that R and the embedding application agree
on the dyl
Seth,
On May 1, 2007, at 5:59 PM, Seth Falcon wrote:
> Simon Urbanek <[EMAIL PROTECTED]> writes:
>
>> Duncan,
>>
>> are you going to take care of this? I have a quick solution for R-
>> devel that adds a special entry if requested.
>>
>> I'm not quite convinced that we need as much flexibility a
Simon Urbanek <[EMAIL PROTECTED]> writes:
> Duncan,
>
> are you going to take care of this? I have a quick solution for R-
> devel that adds a special entry if requested.
>
> I'm not quite convinced that we need as much flexibility as adding
> arbitrary DllInfos, because the embedding applicati
Simon Urbanek wrote:
> Duncan,
>
> are you going to take care of this? I have a quick solution for R-
> devel that adds a special entry if requested.
If you want to go ahead, be my guest.
I'm somewhat occupied for the next few days...
>
> I'm not quite convinced that we need as much flexibili
Duncan,
are you going to take care of this? I have a quick solution for R-
devel that adds a special entry if requested.
I'm not quite convinced that we need as much flexibility as adding
arbitrary DllInfos, because the embedding application is a really
special concept (everything else is dy
Hi,
I'm hoping to get some clarification of the intent of some of
directives used in NAMESPACE files.
1. Is import(somePkg) also intended to import all classes and methods
that are exported via exportClasses and exportMethods in somePkg?
I think import pulls in classes and methods, but it i
Simon Urbanek wrote:
> Since I'm not sure I really understand Jeff's question this is just
> my interpretation, but I think the point was that you may want to
> register symbols *not* from a DLL but from the embedding application
> itself (e.g. like R.app GUI that embeds libR registers its en
Since I'm not sure I really understand Jeff's question this is just
my interpretation, but I think the point was that you may want to
register symbols *not* from a DLL but from the embedding application
itself (e.g. like R.app GUI that embeds libR registers its entry for
quartz.save). I wou
Jeffrey Horner wrote:
> Hello,
>
> The use of .Call and the like all depend on loading shared libraries and
> registering routines from it. Also, .Primitive and .Internal depend on
> routines being registered in the R binary. And applications that embed R
> can override routines declared in Rin
On Mon, 30 Apr 2007 [EMAIL PROTECTED] wrote:
> On Tue, 10 Apr 2007 [EMAIL PROTECTED] wrote:
>
> > I've created a .Rd file (below), then converted that to .sgml using
> > R CMD Rdconv --type=Ssgm combn.Rd > combn.sgml
> > The output (shown below) is missing some of the sections:
> > argume
On Mon, 30 Apr 2007 [EMAIL PROTECTED] wrote:
> On Tue, 10 Apr 2007 [EMAIL PROTECTED] wrote:
>
> > I've created a .Rd file (below), then converted that to .sgml using
> > R CMD Rdconv --type=Ssgm combn.Rd > combn.sgml
> > The output (shown below) is missing some of the sections:
> > argume
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> Note that you called
>
> selectMethod("mget", signature(x="character", envir=class(LLe)))
>
> by name rather than calling the visible function mget() (which you
> could have supplied as fdef). I've never really got to the bottom of
> the complicated
Hello,
The use of .Call and the like all depend on loading shared libraries and
registering routines from it. Also, .Primitive and .Internal depend on
routines being registered in the R binary. And applications that embed R
can override routines declared in Rinterfac.h, but is there a way for a
On Thu, 19 Apr 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Christian Brechbuehler
> Version: 2.4.1 Patched (2007-03-25 r40917)
> OS: Linux 2.6.15-27-adm64-xeon; Ubuntu 6.06.1 LTS
> Submission from: (NULL) (24.61.47.236)
>
>
> Splus and R have different ideas about what qr.coef(qr()) should retur
On Tue, 1 May 2007, Hin-Tak Leung wrote:
> [EMAIL PROTECTED] wrote:
>> This works correctly on Linux. The problem is that the author assumed that
>> atof handles hexadecimal, which it does for a C99 compiler but not
>> apparently on MinGW.
>>
>> We have a workaround for this in mkFloat, and ne
[EMAIL PROTECTED] wrote:
> This works correctly on Linux. The problem is that the author assumed
> that atof handles hexadecimal, which it does for a C99 compiler but not
> apparently on MinGW.
>
> We have a workaround for this in mkFloat, and need to use that for the 'L'
> suffix case too.
K
It really is unclear what is claimed to be a bug here. But see
https://stat.ethz.ch/pipermail/r-devel/2007-May/045592.html
for why the bug is not in R: your old and new data do not match.
Your fit is to a category.
[The problem with the web interface to R-bugs was reported last week: it
is be
> "Stephan" == Stephan <[EMAIL PROTECTED]>
> on Tue, 1 May 2007 13:21:53 +0200 writes:
Stephan> Hi,
>> 0x10L
Stephan> returns: int 0
Stephan> I would expect: int 16? This happens with all
Stephan> integer constants given by hexadecimal notation.
Stephan> It'
Jeffrey Horner wrote:
> There's no RObjectTables.pdf at developer.r-project.org. I included the
> Omegahat URL from the attach help page:
>
> nonexistent
>
>
I took the quicker approach and copied the PDF file to R-dev-web SVN
repo. Should turn up on the website on next mirroring.
-pd
> Inde
[EMAIL PROTECTED] wrote:
> On 01/05/2007 7:21 AM, Stephan wrote:
>
>> Hi,
>>
>>
>>> 0x10L
>>>
>> returns: int 0
>>
>> I would expect: int 16?
>> This happens with all integer constants given by hexadecimal notation.
>> It's a bug?
>>
>
> Certainly looks like one; I've cc'd this
There's no RObjectTables.pdf at developer.r-project.org. I included the
Omegahat URL from the attach help page:
nonexistent
Index: src/include/R_ext/Callbacks.h
===
--- src/include/R_ext/Callbacks.h (revision 41399)
+++ src/in
This works correctly on Linux. The problem is that the author assumed
that atof handles hexadecimal, which it does for a C99 compiler but not
apparently on MinGW.
We have a workaround for this in mkFloat, and need to use that for the 'L'
suffix case too.
On Tue, 1 May 2007, [EMAIL PROTECTED]
On Mon, 30 Apr 2007, Seth Falcon wrote:
> First a bit of disclaimer... I haven't isolated this problem into an
> easy to reproduce case, and I won't be surprised if the root cause is
> a fault in my code's use of name spaces or some such.
Note that you called
selectMethod("mget", signature(x="c
On 01/05/2007 7:21 AM, Stephan wrote:
> Hi,
>
>> 0x10L
> returns: int 0
>
> I would expect: int 16?
> This happens with all integer constants given by hexadecimal notation.
> It's a bug?
Certainly looks like one; I've cc'd this to the bug list (but won't be
able to look into fixing it).
Duncan
Hi,
> 0x10L
returns: int 0
I would expect: int 16?
This happens with all integer constants given by hexadecimal notation.
It's a bug?
> sessionInfo()
R version 2.5.0 (2007-04-23)
i386-pc-mingw32
locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252
I get
worms.glm <- glm(cbind(deaths, (20-deaths)) ~ sex+ doselin,
+ data=worms, family=binomial)
> attr(worms.glm, "dataClasses")
NULL
But maybe the result from somewhere within predict.lm() or model.frame()
is different.
Surely the levels attribute has no relevance to glm's c
26 matches
Mail list logo
